Troubleshooting

@evb I dug into the log parser and it contains this: { re: "!TSF:RTE:DST (\\d+) UNKNOWN", d: "Routing for destination <b>$1</b> unknown, sending message to parent" }, so it is already in the log parser, but the regex is wrong. I think it should look like this: { re: "!TSF:RTE:(\\d+) UNKNOWN", d: "Routing for destination <b>$1</b> unknown, sending message to parent" }, With that change, the log parser looks like this for your message: [image: 1608583928193-19a5c4d3-f29c-428a-9dcf-66bf1819bf6e-image.png] I have created https://github.com/mysensors/MySensors/pull/1462 to fix this.

@Sandolution , @bwn , @electrik Did anyone of you find a solution for this problem?

@mfalkvidd - your response got me thinking about my question some more - the effort required to diagnose/ rework would for little gain, i am thinking its simpler to rework the psu and seperate the NRF from the ESP - its likley that the ESP regulator is only spec'd to power the ESP and not a lot else - lets face it we are not dealing with miltary grade components here lol :) Thanks for the help and support!

No way - found it. Large comment at the top of sketch (not copied to this forum) had a line of *********s across the top. Removed and all ok. Thanks for your help anyway @mfalkvidd

Corrections of the post: ratio= 1.1pow(concentrarion,3)-3.8pow(conccentration,2)+520*concentration+0.62 the graph [image: 1607443162492-123.jpg]

@joaoabs said in Can't receive parent answer: Maybe the slim node page could have some reference to this? I totally agree, the IRQ line should be routed, also for nrf24 modules. Could you propose this in the slimnode maker's thread?

Your takeaway is that there’s a low probability that you will need to buy a replacement for your solar panel before the warranty ends. You can compute the degradation rate if you want the exact figure. If you’re not happy with it, you can always add upgrades to your panels. You just have to make sure that the new parts match with your solar panels.

might be related to that thread: https://forum.mysensors.org/topic/11427

After much tentative-error, found a working setup. The drawback is that the node cannot be more that 4m away from the gateway in order to communication flow normally. Could this be bad quality RFM69's? I mean, isn't supposed that 433MHz range would be higher than this? I was expecting it to cross walls and so... The Slim node is currently powered by a USB/serial adapter (not battery) connected to the laptop so it shouldn't be a low power issue. All nrf2rfm69 modules have a bought 433MHz spiral antenna (like the picture), including the GW and I have also soldered a 10uF SMD tantalum capacitor (smd code 106A) in the back side. [image: $_1.JPG?set_id=880000500F] [image: s-l400.jpg]

Well, After removing some counters cycles on a node, I can state I have the MySensors GW working non-stop for 24h now with 2 nodes without any noticeable issue. Both nodes are using Encryption and Signing. The nodes are simply reporting temperature and Humidity every minute or so. Will try now the behavior with actuator nodes (relay). In the log I can see it isn't perfect yet. There are quite a few signing failures. The node #80 is 6 meters away from the gateway with line-of-sight, which concerns me a bit because when I place the nodes in the final locations, I'm sure the radio path will not be better than this. I'm assuming that the signing is failing due to radio issues - I might be wrong. Dec 03 17:46:12 DEBUG TSF:MSG:READ,80-80-0,s=20,c=1,t=0,pt=7,l=5,sg=1:14.0 Dec 03 17:46:12 DEBUG SGN:BND:NONCE=326B170BBDFD3CE66C91DE485E2C465D98434C6917C4D7269DAAAAAAAAAAAAAA Dec 03 17:46:12 DEBUG SGN:BND:HMAC=602409810E55FA10445022FEECCB08697878B9F0FD1652B9303FF9D543B240FD Dec 03 17:46:12 DEBUG SGN:VER:OK Dec 03 17:46:12 DEBUG GWT:TPS:TOPIC=mysensors-out/80/20/1/0/0,MSG SENT Dec 03 17:46:13 DEBUG TSF:MSG:READ,80-80-0,s=40,c=3,t=16,pt=0,l=0,sg=1: Dec 03 17:46:13 DEBUG SGN:SKP:MSG CMD=3,TYPE=16 Dec 03 17:46:13 DEBUG SGN:SKP:MSG CMD=3,TYPE=17 Dec 03 17:46:13 DEBUG TSF:MSG:SEND,0-0-80-80,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE> Dec 03 17:46:13 DEBUG SGN:NCE:XMT,TO=0 Dec 03 17:46:13 DEBUG TSF:MSG:READ,80-80-0,s=40,c=1,t=1,pt=7,l=5,sg=1:63.0 Dec 03 17:46:13 DEBUG SGN:BND:NONCE=854FF116C7AA8566A8176AAA1A319BE95D90D8417AA92EDB3EAAAAAAAAAAAAAA Dec 03 17:46:13 DEBUG SGN:BND:HMAC=C54BAC9E3FE050E9170CEE17AB23836A98EA270ADFC089A4523E27610D587E88 Dec 03 17:46:13 DEBUG SGN:VER:OK Dec 03 17:46:13 DEBUG GWT:TPS:TOPIC=mysensors-out/80/40/1/0/1,MSG SENT Dec 03 17:46:14 DEBUG TSF:MSG:READ,80-80-0,s=21,c=3,t=16,pt=0,l=0,sg=1: Dec 03 17:46:14 DEBUG SGN:SKP:MSG CMD=3,TYPE=16 Dec 03 17:46:14 DEBUG SGN:SKP:MSG CMD=3,TYPE=17 Dec 03 17:46:14 DEBUG TSF:MSG:SEND,0-0-80-80,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE> Dec 03 17:46:14 DEBUG SGN:NCE:XMT,TO=0 Dec 03 17:46:14 DEBUG TSF:MSG:READ,80-80-0,s=21,c=1,t=0,pt=7,l=5,sg=1:8.0 Dec 03 17:46:14 DEBUG SGN:BND:NONCE=BA1DABAF567A20CEABF5CFC35D638E7A1A3E5CF94204D96935AAAAAAAAAAAAAA Dec 03 17:46:14 DEBUG SGN:BND:HMAC=8735CDA75D1148784B3D73601E7A4199DB44CFD039C75584EBA9ADD24897355A Dec 03 17:46:14 DEBUG SGN:VER:OK Dec 03 17:46:14 DEBUG GWT:TPS:TOPIC=mysensors-out/80/21/1/0/0,MSG SENT Dec 03 17:47:15 DEBUG TSF:MSG:READ,80-80-0,s=20,c=3,t=16,pt=0,l=0,sg=1: Dec 03 17:47:15 DEBUG SGN:SKP:MSG CMD=3,TYPE=16 Dec 03 17:47:15 DEBUG SGN:SKP:MSG CMD=3,TYPE=17 Dec 03 17:47:16 DEBUG TSF:MSG:SEND,0-0-80-80,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE> Dec 03 17:47:16 DEBUG SGN:NCE:XMT,TO=0 Dec 03 17:47:16 DEBUG TSF:MSG:READ,80-80-0,s=20,c=1,t=0,pt=7,l=5,sg=1:14.0 Dec 03 17:47:16 DEBUG SGN:BND:NONCE=EF0F98582847EC766BDBC6FB13B7920FCB68CA984C600DA0FBAAAAAAAAAAAAAA Dec 03 17:47:16 DEBUG SGN:BND:HMAC=7AB74FA813953F8965393306FFF67FCA429DCE7F293E08357B9AAE4B0D33C5C1 Dec 03 17:47:16 DEBUG SGN:VER:OK Dec 03 17:47:16 DEBUG GWT:TPS:TOPIC=mysensors-out/80/20/1/0/0,MSG SENT Dec 03 17:47:17 DEBUG TSF:MSG:READ,80-80-0,s=20,c=1,t=0,pt=7,l=5,sg=1:14.0 Dec 03 17:47:17 DEBUG !SGN:BND:VER ONGOING Dec 03 17:47:17 DEBUG !SGN:VER:FAIL Dec 03 17:47:17 DEBUG !TSF:MSG:SIGN VERIFY FAIL Dec 03 17:47:17 DEBUG TSF:MSG:READ,80-80-0,s=20,c=1,t=0,pt=7,l=5,sg=1:14.0 Dec 03 17:47:17 DEBUG !SGN:BND:VER ONGOING Dec 03 17:47:17 DEBUG !SGN:VER:FAIL Dec 03 17:47:17 DEBUG !TSF:MSG:SIGN VERIFY FAIL Dec 03 17:47:18 DEBUG TSF:MSG:READ,80-80-0,s=20,c=1,t=0,pt=7,l=5,sg=1:14.0 Dec 03 17:47:18 DEBUG !SGN:BND:VER ONGOING Dec 03 17:47:18 DEBUG !SGN:VER:FAIL Dec 03 17:47:18 DEBUG !TSF:MSG:SIGN VERIFY FAIL We can see in the log that the same node/child have both successful signing as well as failed signing. This signature failure isn't critical for temp/Humidity readings (even if it fails now, it will be fine in the next round), but for actuator nodes (where you really want something to be turned on/off) it will be a concern. I haven't noticed any other 433MHz interference (but only used the garage remote a couple of times during the day). It can be that a buggy node sketch makes the RFM69 unstable and jams the frequency. One of the side effects is that there are no entries in the GW log and therefore it seems is it down. Well, something to take into consideration when coding the nodes. My 2 cents

Hi, Got it working! It was a strange mix of RFM69/RFM69HW devices (all soldered into the nrf2rfm69 board - so couldn't tell which type it was) and also a faulty RFM69. Also, it seems the signing consumes much processing power (and memory) to the little at328 chips. A sketch with more than 65% memory usage may fail some signatures, so not recommended to put many functionalities in the same node, specially when running my_debug. Simple sketches just with a sht21 sensor are working fine with signing and RFM69 encryption. Copying the correct HMAC, soft-serial and AES to the mysensors.conf file and with RPI reboots after each config/make/makeinstall cycle solved the problem. Thanks, Joaoabs

@joaoabs said in Error compiling for RPI4 64 bit: RFM69_MAX_PACKET_LEN: Maybe MySensors isn't yet ready for 64bit It won’t be until someone wants it badly enough, and has the time and skills to do whatever is needed. You seem to have made some progress. Hopefully you or someone else can figure out how to proceed.

thank you for this additional information. Tristan

Hi, I was looking for this! How can I get this docker container? Cheers, Joaoabs

@mhdayusuf Do you have a copy of the changes you made? I am quite struggling to make it work and is not obvious to me what changes you made... Thanks.

Great work @benhub, thanks for reporting back.

I think this is the same thing as you were trying to accomplish. Sleep for 6 minutes or when interrupted. I have a reed switch on pin 2 pinMode(REED_SWITCH, INPUT); // set the reed switch digital pin as input //digitalWrite(REED_SWITCH, HIGH); pinMode(REED_SWITCH, INPUT_PULLUP); sleep(digitalPinToInterrupt(REED_SWITCH), CHANGE, 360000); //3600000 hour

@Yveaux Makes sense now. Thanks again. :hugging_face:

@frits : This is my first GW, but during my early experiments I run it as an Ethernet GW, then I reconfigured to MQTT. Currently I don't have a controller running but I'm using Node-Red + Influx-DB + Grafana. So probably during these first experiments, while in Ethernet mode, the Node_IDs were distributed. I will erase the EEPROMs by the next opportunity and will check the behaviour of my Nano sensors after re-boot. Thanks for your explanation frits, it helped me to learn more about MySensors.:+1:

@Robert said in Suspending the node: Which bootloader should I use? Only you can decide the best one for what you want. Is it necessary in my case? I would say yes it is if you want WDT to operate. Does users mysensors change the bootloader? That depends on the need case for each individual requirement. Some do, some don't. The ones that do have a specific reason for doing so, like fota or wdt. Mysensors has its' own bootloader and I believe that it supports WDT. Optiboot is another popular one but I don't personally know if it supports WDT.