@hek I was able to add support for stream message types to the log parser but can't perform a pull request against the gist. Here is my diff analysis if you're interested in this small update.
I also made a subsequent one line change to correct the issue that @BoresExpress noted a while back.
@meach Configure is not seeing the = in your command line properly - so I'm assuming a cut+paste issue with character strings.
Ie. It's seeing the configuration option --my-mqtt-user=pi instead of --my-mqtt-user and a value of pi.
Try to retype that part of the command line manually and try it again.
A
EDIT: As an aside, I usually put my configure command line into a script and then just run the script. Handy when you come back to it 6-8 months later and wonder what configure options you used the last time you ran it.
I've recently been updating my nodes and gateways to use the latest version of MySensors. I've also recently acquired a handful of Sensebender Micros and set one up in the pool shed to test/play and get some outside temperature and humidity readings. A problem I found though is that I was getting some anomalous data readings which completely throws off my time period data - see the 24-hour chart below.
Solar flares perhaps? I ruled that out.
I set up a test last night before turning in for the night and ran it for about 18 hours. I've collected and compared the debug logs of my node with those of the Ethernet and MQTT gateways that I have and found that the node is sending a valid float value at all times but the gateways will sometimes receive something different.
Node Debug Data (stripped to just the sending of one of the sensors)
4935 TSF:MSG:SEND,4-4-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:21.6
5480 TSF:MSG:SEND,4-4-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:21.2
6891 TSF:MSG:SEND,4-4-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:20.7
8331 TSF:MSG:SEND,4-4-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:20.4
And corresponding receives from the Ethernet Gateway debug log
Jun 04 00:55:20 DEBUG TSF:MSG:READ,4-4-0,s=1,c=1,t=0,pt=7,l=5,sg=0:21.6
Jun 04 01:02:35 DEBUG TSF:MSG:READ,4-4-0,s=1,c=1,t=0,pt=5,l=5,sg=0:1101633946
Jun 04 01:37:38 DEBUG TSF:MSG:READ,4-4-0,s=1,c=1,t=0,pt=7,l=5,sg=0:20.7
Jun 04 02:13:52 DEBUG TSF:MSG:READ,4-4-0,s=1,c=1,t=0,pt=7,l=5,sg=0:20.4
You can see that the data received changed payload type from P_FLOAT32 (pt=7) to P_ULONG32 (pt=5) !!!
Note that the graph above is from data collected by way of the MQTT gateway and as such doesn't specifically correspond to the debug logs above but I do see exactly the same flip of payload type in the MQTT GW log - though at different times from those in the Ethernet GW log
Now I understand that this is going to come down to noise in the radio transmission but it raises some bigger-picture questions for me.
I'm at a loss on how best to ensure the integrity of the data being sent and collected. What are your thoughts?
Allen
There's a broken link in the reference for MY_OTA_FIRMWARE_FEATURE in the Configuration section above (https://www.mysensors.org/download/sensor_api_20#configuration). I believe the correct URL should be https://www.mysensors.org/about/fota.
Figured out that I misunderstood the purpose of this directive. I was thinking (had assumed) that it was showing more verbose information through the serial output for firmware OTA update traffic. Once I looked at the description for it, it was clear that it is intended more as an alternative to MY_DEBUG - as in don't send debug output to the serial but send it over-the-air instead. I was declaring both and they conflict.
EDIT: saying they conflict is inaccurate. The problem was in how I was using it (inappropriately).
-- Allen
@mfalkvidd Thank you - MY_DEBUG_VERBOSE_OTA_UPDATE does look like it's exactly what I was looking for. Further looking into the code here though, it would seem that it gets defined automatically if we define MY_DEBUG.
Turn it around, when we define MY_DEBUG, we should see verbose FOTA (+ Core, Transport and Gateway) information in the serial log output.
I'll attempt some more testing tonight to see what I can see.
@Anticimex I had to turn off MY_DEBUG to add the encryption directives. I also moved everything back to version 2.3.1 as I was still seeing some weird stuff going on like msg-type 169 (unknown) and attempts to route through nodes that don't exist. These things I guess may have been due to high ram usage. I think I was at about 78% w version 2.3.2 and basic encryption enabled but now...
Sketch uses 21542 bytes (70%) of program storage space. Maximum is 30720 bytes.
Global variables use 1108 bytes (54%) of dynamic memory, leaving 940 bytes for local variables. Maximum is 2048 bytes.
@Yveaux - I don't expect that it would have been high ram usage causing my initial issues as I wasn't using any encryption or signing before. I started seeing these problems when I moved to 2.3.2 but as I had also been dealing with a new sensor on my first Sensebender Micro, I wasn't sure what might be causing the problems. What do you think might have caused the received data type to flip from a float to an unsigned integer?
@Anticimex I've got it set to measure once per minute at the moment and force transmissions that have no changes every 30 but that's my testing stance. In the end, it'll likely be more of a 5 or 10-minute measurement and forced hourly.
@Anticimex Thanks. I've done some preliminary research into signing and encryption and have struggled a bit with taking it from concept to implementation. I guess I should roll up my sleeves and dig into the how-tos. This is intended to be a battery-powered sensor so perhaps I'll start with encryption first.
I've recently been updating my nodes and gateways to use the latest version of MySensors. I've also recently acquired a handful of Sensebender Micros and set one up in the pool shed to test/play and get some outside temperature and humidity readings. A problem I found though is that I was getting some anomalous data readings which completely throws off my time period data - see the 24-hour chart below.
Solar flares perhaps? I ruled that out.
I set up a test last night before turning in for the night and ran it for about 18 hours. I've collected and compared the debug logs of my node with those of the Ethernet and MQTT gateways that I have and found that the node is sending a valid float value at all times but the gateways will sometimes receive something different.
Node Debug Data (stripped to just the sending of one of the sensors)
4935 TSF:MSG:SEND,4-4-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:21.6
5480 TSF:MSG:SEND,4-4-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:21.2
6891 TSF:MSG:SEND,4-4-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:20.7
8331 TSF:MSG:SEND,4-4-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:20.4
And corresponding receives from the Ethernet Gateway debug log
Jun 04 00:55:20 DEBUG TSF:MSG:READ,4-4-0,s=1,c=1,t=0,pt=7,l=5,sg=0:21.6
Jun 04 01:02:35 DEBUG TSF:MSG:READ,4-4-0,s=1,c=1,t=0,pt=5,l=5,sg=0:1101633946
Jun 04 01:37:38 DEBUG TSF:MSG:READ,4-4-0,s=1,c=1,t=0,pt=7,l=5,sg=0:20.7
Jun 04 02:13:52 DEBUG TSF:MSG:READ,4-4-0,s=1,c=1,t=0,pt=7,l=5,sg=0:20.4
You can see that the data received changed payload type from P_FLOAT32 (pt=7) to P_ULONG32 (pt=5) !!!
Note that the graph above is from data collected by way of the MQTT gateway and as such doesn't specifically correspond to the debug logs above but I do see exactly the same flip of payload type in the MQTT GW log - though at different times from those in the Ethernet GW log
Now I understand that this is going to come down to noise in the radio transmission but it raises some bigger-picture questions for me.
I'm at a loss on how best to ensure the integrity of the data being sent and collected. What are your thoughts?
Allen
What I had noticed and was trying to point out was that the error was:
[WARNING] Unknown option detected: --my-mqtt-user=pi, ignored
not:
[WARNING] Unknown option detected: --my-mqtt-user, ignored
@meach Configure is not seeing the = in your command line properly - so I'm assuming a cut+paste issue with character strings.
Ie. It's seeing the configuration option --my-mqtt-user=pi instead of --my-mqtt-user and a value of pi.
Try to retype that part of the command line manually and try it again.
A
EDIT: As an aside, I usually put my configure command line into a script and then just run the script. Handy when you come back to it 6-8 months later and wonder what configure options you used the last time you ran it.
@trs-80 said in OpenHAB 2.4 MySensors Serial Gateway - How to install:
Currently, it seems there is some bug going on with their build system or something. I actually had lodged an issue of my own (and even had submitted a PR to correct the documentation) before someone replied, pointing me to the root issue. So for the time being, instead of using https://dl.bintray.com/openhab/apt-repo2 location, you should use https://openhab.jfrog.io/openhab/openhab-linuxpkg repository location.
I ran into the same thing. Specifically, to get around this, the second instruction under the OpenHAB portion of the original post can be substituted with this:
echo 'deb https://openhab.jfrog.io/openhab/openhab-linuxpkg stable main' | sudo tee /etc/apt/sources.list.d/openhab2.list
EDIT: I've just noticed that they've updated the Package Repository Installation instructions to add the command above.
Further, if you care about issues such as software freedom (which I do a great deal) you might want to consider installing Azul/Zulu Java 8 (make sure it's 8!) which I have done, instead of Oracle Java. Azul's (also excellent) instructions can be found linked from the OpenHAB Linux install instructions. And that would also solve your missing repo problem, obviously.
If using Zulu Java, beware that the repos are not being maintained and are behind (see reference for manual instructions).
I used OpenJDK 8 for java with sudo apt install openjdk-8-jdk-headless.
I'm using an Ethernet gateway (on a separate Raspberry Pi) though which is a twist on all of this.
--Allen
@hek I was able to add support for stream message types to the log parser but can't perform a pull request against the gist. Here is my diff analysis if you're interested in this small update.
I also made a subsequent one line change to correct the issue that @BoresExpress noted a while back.
@mfalkvidd Thank you - MY_DEBUG_VERBOSE_OTA_UPDATE does look like it's exactly what I was looking for. Further looking into the code here though, it would seem that it gets defined automatically if we define MY_DEBUG.
Turn it around, when we define MY_DEBUG, we should see verbose FOTA (+ Core, Transport and Gateway) information in the serial log output.
I'll attempt some more testing tonight to see what I can see.