Currently I'm using rechargeable AAA, which will be switched soon, as the sensor is working fine.

Why would you switch the batteries?

5.2V / 4 = 1,3V so still quite full.

These batteries are low-leakage batteries so provided the initial charge is fine and current consumption the lifespan should be good and at least 50% of that of good alkaline batteries

If the sensor and the gateway are at the same level or about the same level I think using a half-wave dipole or "rubber duck" antenna pointed vertically is a good idea.

That will focus the energy in the horizontal plane and not into the ground or to the air giving about 2 dBi of gain.

Although it should not be too difficult to make the MQTT Gateway with WiFi work on hardware and software level it is a bad idea on system level:

WiFi and MySensensor NRF24L01+ use the same 2.4 GHz band and with the antennas close a transmit from one will block the other and vice-versa.

@shabba You ask for the plane for the antenna but to for that it is handy to describe your house or setup, one or multiple floors, concrete walls etc?

@rvendrame:

• The ZWave paper you point to describes a problem implementation, not the protocol itself it seems to me:

The root cause of this issue was lack of state validation
in the key exchange protocol handler programmed in the Z-
Wave door lock firmware.

• Yes, if you lose your normal key anybody that knows to which lock it belongs can break in.
• But, if your key has no information on to which lock it belongs to the risk is small, the same is true for a remote.

You should not typ "\n"!
It means that you should press enter on your keyboard.

On Linux I saw that I have to send "\r\n" instead of "\n".
"\r\n" (Carriage return, Line feed) is the Windows return, "\n" only the Linux return.

What kind of protocol is the 433 MHz RF running?

@tekka : Thanks, things work now fine! :+1:

Did do some more experimenting using a sort of Ethernet gateway (actual the relayed Serial gateway data) and see that MYSController.exe can connect but once it prints the first data it gives the "File not open." error and no further data is printed.

So it does not look like a serial port issue but something else.

Did not know Lazarus but it looks pretty good!

I have AutoFW disabled.

The funny thing is that things do not work at all if I do not get the "File not open" error.
No, rebooting the gateway does not make the "Gateway startup complete" message re-appear.

Did watch the serial port using interceptty and see data is passed so it seems like Wine is not passing it.

Would be good to move the last five message into a separate thread...

Yes, signing, when properly done, is for sure a good begin.

How many bytes are you using for the truncated MAC and nonce?

The AES block size is 128 bytes, so 16 bytes so I do not see why that would not fit.

Encryption is already some kind of authentication is a sense that if you can successfully decode the message you can be sure that the other side knows the shared secret, just like in the cause of your SHA25-HMAC.

what benefit is there from encryption vs signing in the MySensors case?

If you have a lock or door sensor do you want others to know when it is opened or closed?

Signing is quite expensive if you look at additional payload size, you need a big counter to prevent replay and a big MAC to prevent attacks. I think that when encrypting things you can do it with the same additional payload and maybe even a less.

Doing OTA did work once but trying a second time did not work out yet.

I found that it is important the user that runs "wine MYSController.exe" must have access to the port ~/.wine/dosdevices/COMx links to:

$ ls -als /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_*
0 lrwxrwxrwx 1 root root 13 25 jan 09:38 /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9SZN99X-if00-port0 -> ../../ttyUSB0

Is not good ("root root"), I changed the link to to:

$ ls -asl /dev/ttyUSB0 
0 crw-rw---- 1 root dialout 188, 0 25 jan 11:34 /dev/ttyUSB0

In the debug log I see the 0;0;3;0;14;Gateway startup complete. message but no messages from the sensor.

Looks like the "File not open." window I am getting and:

fixme:comm:set_queue_size insize 4096 outsize 0 unimplemented stub

I am seeing on the command line has something to do with it.

NB: Seems like the GUI is programmed using TK. How about compiling it for Linux?

What kind of error do you get?

@olaeke : Thanks!

So in total four devices meaning, the Node itself and a device for every (Child)-Sensor. Makes sense.

Just wondering what other Controllers are doing here. I think at least some completely ignore the child node numbering and either put all values without context or all values under the Node.

Suppose I have a Node with:

• Node ID = 7
• Child nodes 3, 11, and 21:
• Child node 3 sends a presentation S_TEMP followed by a set V_TEMP
• Child node 11 sends a presentation S_POWER followed by a set V_WATT, V_KWH and V_VOLTAGE
• Child node 21 sends a set V_TEMP, V_HUM, V_PRESSURE, V_RAIN, V_DIRECTION and V_UV

How is that displayed in Vera?

That chip is still only for authentication, only it's with aes-128 message auth instead of sha 256

If I have a look at the datasheet I see:

Opcode Name        Description
0x06   Encrypt     Encrypts 16 or 32 bytes of plaintext data provided by the Host.
0x07   Decrypt     Decrypts 16 or 32 bytes of data provided by the Host after verifying the integrity MAC.

So it does encrypt/decrypt.

The CryptoCape board has both ATSHA204A and ATAES132 where the ATAES132 can "Encrypt up to a 32 byte packet at a time with AES-128-CCM"

Not sure if it is handy to have the integrity MAC combined as that does require 16 additional bytes, but that is the same story for SHA-256.

Okay, clear, thanks!

Did you have a look at the serial output of the Light Lux Sensor sketch on the Trinket?