@otto001 Thanks for that! I'm also getting this annoying service failure on 2.2 on a RPi 2. It seems to happen at random at night when nothing much is going on in the house. It probably happens once every 1 to 2 weeks.
CPU use is almost 100% and the service stops working.
Are there any logs I can check? I'd prefer to know what's wrong although I'll go with the auto restart on high cpu use to prevent the house from ceasing to function at random!
Best posts made by Nick Willis
-
RE: 💬 Building a Raspberry Pi Gateway
-
RE: NodeManager v1.7-beta: feedback needed
Hi I've just started with NodeManager but not with MySensors. I've been writing my own sketches up to now but am impressed with NM's v1.7 as it makes so much sense and avoids so much of the repetition and debug time with manual coding.
I've got a DHT22 node up with 1.7 - nice and easy. I noticed the FEATURE_CONDITIONAL_REPORT feature and would like to know how to use it as it isn't covered in the documentation yet.
Since the sensor can often fluctuate by 0.1c (and humidity even more so) I'd like to only report for 'genuine' changes. Something like:- If the value changes by more than 0.1c since the last value was reported, then report immediately. Otherwise don't report yet.
- Report anyway after 5 minutes if no report was made. This 5 minutes would get reset if a report was made by the first >0.1c condition.
I think that makes sense although open to ideas on the best way to keep regular but not too regular sensor reports.
Looking forward to rolling out NM across my sensor network and expanding! -
Occasional MySensors network drop outs
Occasionally the whole of the MySensors network will drop out and I'm trying to figure out why.
My system:
Raspberry Pi 2 gateway with nothing else running on the Pi.
I have 10 active sensors and most are built using the Newbie PCB running off either batteries or 5v USB power sources. Most sensors are a mix of DHT22, PIRs and MPR121 touch sensors.
I use Home Assistant for automation & data logging.Most of the time everything just works, but on occasion everything MySensors will just stop - meaning the motion sensors that control lighting and the light switches much to the annoyance of the wife who claims my smart house isn't so smart :). I know its MySensors as the other half of my system runs on Tinkerforge sensors which are rock solid. Whilst the system is down if I check MYSController I see no messages on the network. Connection to the gateway Pi doesn't go down (HomeAssistant will log this). After 5 or so minutes (without intervention) it'll come back up.
There are no messages in the MySensors service log and obviously checking the sensor serial logs is not so simple on deployed sensors especially as this problem is quite random. It might happen more often than I know but is far more obvious at night (but its summer so night doesn't start until 2130 so so far not a major problem but come winter's pre 1600 sunsets it'll be more challenging!).How do I go about debugging this situation? I thought about deploying a sensor that checks in every 10 seconds to spot the drop outs. Doesn't solve it though however. I don't feel like my comms is at fault as then it wouldn't affect all sensors. All sensors have a cap on the NRF radio.
Tips greatly appreciated! -
RE: Something's cooking in the MySensors labs...
I've been using this PR on my gateway for several months now and it's working great. I'm using a Sensebender gateway with both RFM and NRF radios with sensor nodes on both networks. I can swap radio types on a node, change the radio config in the sketch (keeping the node ID) and it flawlessly changes and continues to work in Home Assistant.
Only thing that is behaving oddly are RFM radio nodes. When they first boot they can pair to the gateway no problem but then suffer NACKs constantly for 3 or 4 mins after which it works no problem for weeks and months... I can see the NACKed messages arriving at the gateway but the node doesn't recieve the ACK from the gateway.
I also note that all other RFM nodes start NACKing at the same time (I have a NACK monitor sensor on all my nodes) which again clears up once the new node has been on a few minutes. It's the same whenever any RFM node is rebooted.
I'm not using this PR version on my nodes - only the gateway - as some things would not compile.
Hope this feedback is of use! -
MySensors gateway and network reliability
I've been working with MySensors for several years and have 20 active nodes running doing all sorts of jobs.
One thing I've constantly battled with is reliability. Missed messages are the primary problem. To fully understand the scale of the problem I wrote an app for my controller (Home Assistant) that sends a VTEXT message 'PING' to which my nodes will reply 'ACK'. It does this every 10 seconds. I can then visualise this data in Grafana to get plots of reliability:
I was using a Raspberry Pi gateway for a long time but I'd get quite a few drop outs sometimes with nodes down for hours at a time sometimes. I'm now using a Arduino Mega Ethernet gateway and after trying a few RF24 radios (and buying recommended good quality ones) found I get very few drop outs - although as you can see i'm still getting some. But more annoying is the whole gateway dropping out like it did this morning - on the first day of being away for a week. Hence all are marked FAIL currently. The 'fix' is to hit the reset button on the Mega and it'll go again. But that's not possible 1000+ miles away... It only totally fails every few weeks at the most but still no good as now all my sensors are off. Very glad its now cold or my garden irrigation would be down!
I'm writing to ask what tips others have on improving MySensors reliability. Even a short drop out is annoying or in the case of door sensors renders my security system useless. But the whole gateway going is very annoying. I switched away from the Pi because it would crash from time to time but didn't expect the Mega to crash too. Perhaps I could build some device to hard reset the device if the gateway goes down. I can still ping the gateway but no controllers can connect to it.
As for the nodes perhaps I could add onto my sketches a way to get a confirmation that the message has arrived at the controller otherwise keep trying x numbers of times until it does. For temperature sensors there's no point but door/window sensors... or motion sensors perhaps too.What are others doing here to improve their MySensors network? I already switched to channel 50 on the MyS network but haven't experimented much further with channels as its a big job to reprogram every node to change channels. All my nodes use the Newbie PCB with caps on the radios, etc. I try to use good power supplies (from Ikea mostly). All nodes/gateway use MySensors 2.3.1. I'm in an apartment block in the city centre so I'm sure there's a lot of radio and electrical noise. But my wifi always works (well almost always) and I'd like MySensors to be at least mostly reliable especially the gateway.
Bit of a long rambly message but any tips very welcomed!
-
RE: MySensors gateway and network reliability
Thanks for the responses and kind of what I expected. The lack of 'guarantee of service' is a big big problem in MySensors. My system works 'most' of the time but that isn't good enough for anything critical. And with no real pattern to getting things reliable it seems we can only get 95% of messages through at very best.
I really like the concept of MySensors especially as buying lots of 'smart' devices that go on the IP network worries me from a security point of view. I like that you can just hook up any old sensor to an Arduino and get data logged and automations going very quickly.Switching to RFM69 I have considered but I'd basically be starting again as all my existing nodes would need new PCBs + radios. I guess I could try it out then shift over the 'critical' stuff to the reliable network but keep the existing one up for environmental sensing. It's hard when its basically working 'most' of the time. But would that stop the gateway from crashing though? I don't know why it fails so its tricky to know how to respond.