LoRa appKey and appEUI can i randomly generate ? or anything else...
Example:
AppEUI (8 bytes, example): 424152414E490000 (random value)
Appkey (16 bytes, example):424152414E492044455349474E000000 (random value)
You can use random AppKeys for your devices. (It is recommended that every device has a different AppKey.) Please note that the AppKey you provision on the LoRaWAN network server must be the same as the one your LoRaWAN end device is personalized with.
The purpose of the AppEUI is to identify the Join Server of your home network. When your device sends a Join Request to the network server it will forward it to the Join Server of your device. Therefore, it is essential the you personalize your end device with a proper AppEUI.
However, in case your network server is not connected to any external Join Server and processes all Join Requests by itself, the AppEUI is not used for anything and you can use a random EUI. It is still important that the AppEUI provisioned on the network server is the same as the one the device is personalized with.
Related
I've been working for 2 months in a MODBUS project and now I found a problem.
My client is asking me to write in an input register (Address 30001 to 40000).
I thought that was not a thing for me because every modbus documentation says that 30001 to 40000 registers are read-only.
Is it even possible to write in those registers? Thanks in advance
Both holding and input register related functions contain a 2-byte address value. This means that you can have 65536 input registers and 65536 holding registers in a device at the same time.
If your client is developing the firmware of the slave, they can place holding registers into the 3xxxx - 4xxxx area. They don't need to follow the memory layout of the original Modicon devices.
If one can afford diverging from the Modbus standard, it's even possible to increase the number of registers. In one of my projects, I was considering to use Preset Single Register (06) function as a bank select command. Of course, you can't call it Modbus anymore. But, the master can still access the slave using a standard library or diagnostics tools.
You can't write to Input Contacts or Input Registers, there is no Modbus function to write to them, they are read only by definition
Modbus is a protocol and in no case specifies where the values are stored, only how they are transmitted
Currently there are devices that support 6-digit addresses and therefore can address up to 65536 registers per group
I've managed to simulate a single slave device on my raspberry pi using node-red using functions to send data random values to the Modbus flex server. However, now I want to be able to simulate multiple Modbus slave devices on the port number and I'm unsure how to do this.
I've tried creating another Modbus flex server with the same port number, but this causes the whole node-red application to crash when it's deployed. Secondly, I've tried using different Modbus flex-write nodes to simulate different slave devices, but I'm unsure whether this is correct and if so, how I'd configure them to appear as different slave devices. This is because so far, my raspberry pi appears as slave 1, but I'm unsure where this comes from. I'm guessing it's to do with the unit-id of the Modbus flex-server but when I change the unit-id to a different number and type that number as the address in the master, it says no connection.
In conclusion, is it possible to use a single raspberry pi to simulate multiple slave devices on node-red using node-red-contrib-modbus and if so how do you do it?
The concept of Slaves in Modbus TCP differ somewhat from RTP as set out in the Modbus TCP Spec:
The MODBUS ‘slave address’ field usually used on MODBUS Serial Line is
replaced by a single byte ‘Unit Identifier’ within the MBAP Header.
The ‘Unit Identifier’ is used to communicate via devices such as
bridges, routers and gateways that use a single IP address to support
multiple independent MODBUS end units.
So there is a difference in termanalogy between Modbus RTP and TCP as well as a difference in the intended use of this field. The solution suggested by the spec would be to setup multiple servers on different ports (you cannot run multiple servers on a single port).
Having said that some TCP->RTP gateways (and other devices) use the unitid as the slave ID so I'm assuming you are trying to simulate something like this?
The first issue is that there appears to be a bug in Modbus Flex Server (reported) in that when you change the unit-id it is being stored as a string rather than a number. If you export the flow you will see something like "unitId": "3",; changing this to "unitId": 3, (no quotes around the 3) and importing fixes the issue (so that probably explains why you could not get this working).
Having said that changing the unit-id like this does not help you because it only supports one ID. However if you set the unit-id to 255 then it will listen on all unit-ids (this is a feature of the modbus-serial module used internally). Remember that you will currently need to manually fix the config to get this to work due to the bug.
Having done that you can do something like the following to respond to requests to different unit ids (the example will return the unit id (1 or 2) for all addresses so is not useful but shows the concept):
I am a little bit confused about the LoRaWAN security mechanism.
The NwkSKey is used by both the network server and the end-device to
calculate and verify the MIC (message integrity code) of all data
messages to ensure data integrity.
The AppSKey is an application session key specific for the end-device.
It is used by both the application server and the end-device to
encrypt and decrypt the payload field of application-specific data
messages
So technically the Network server does not know the AppSKey.
What I dont understand is that in the OTAA procedure, the network server responds with a Join-accept that is encrypted using the AppKey. So if the network server has already the AppKey, it can generate the AppSKey using this formula:
AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce | pad16)
In that case the network server if he would like to it can decrypt the message destinated to the application.
Is my analysis correct or I am missing something?
Thanks and best reagrds!
Got the answer on the TTN forum:
https://www.thethingsnetwork.org/forum/t/lorawan-security-can-the-network-server-generate-the-appskey/8672
I have an Ethernet card in a Omron PLC. Is there any way to do an automatic check to see if the Ethernet card is working? If not, is there a manual way? For example, if the card was to go out on the PLC it would give an error. But if the card just loses signal with the server then it would NOT give error. Any help on how to do this?
There are several types of errors you can check for. The way you do this depends on the type of error. Things you can check :
ETN unit Error Status (found at PLC CIO address CIO 1500 + (25 x unit number) +18)
What it reports : IP configuration, routing, DNS, mail, network services, etc, errors.
See : Manual Section 8-2
The ETN unit also keeps an internal error log (manual section 8-3) that you can read out to your HMI software (if you use it) using FINS commands. This documents all manner of errors internal to the ETN unit.
There are also other memory reservations in the PLC for CPU bus devices (like the ETN unit) which provide basic status flags you can include in ladder logic to raise alarms, etc. (See section 4-3 : Auxiliary Area Data).
These flags indicate whether the unit is initializing, for example, has initialized successfully, is ready to execute network commands, whether the last executed command completed OK or returned an error code (which can be read from the Error Log as above), etc. These can indicate whether the PLC is unable to properly communicate with the ETN device.
You can implement single byte location which will be autoincremented each second by the server. Then every few seconds you check in your PLC logic if old reading is the same as new reading, and if it is then you trigger an alarm that physical server (which is an communication client) is not communicating to PLC ethernet card.
I'm trying to understand the difference between:
3 - Deauthenticated because sending STA is leaving (or has left) IBSS or ESS.
4 - Disassociated due to inactivity.
Both sent from a client to the AP, I'm trying to find what triggers them.
Just as a client will authenticate (verification of credentials) and associate (approve to send data in the Service Set) the client must also deauthenticate (credentials are no longer valid) and disassociate (which terminates the connection).