We tend to rely more and more on our clever electronics these days – but here’s a timely, cautionary tale! My friend MAT over at NotEnoughTech has just TODAY written about the Tonga volcano and one of his Zigbee sensors which includes not only temperature but also a (generally) not entirely interesting barometric pressure sensor. I suggest a quick look at his blog entry if you are interested in the Tonga volcano disaster and how such events may or may not affect your sparkly new sensors.
But of course this is not new and it doesn’t need a massive, distant wayward volcano or other such events to reduce your sensors to a pile of poo – much less significant events much closer can of course achieve the similar results (hindsight is a wonderful thing). I left our home in Southern Spain for a trip to the UK back in November and will soon be heading back – hopefully all will be well (except for two sensors – read on…). It is in situations where the sensors are remote and inaccessible that the real problem lies with external interference.
Shortly after I arrived in the UK I checked the same Aqara sensor type back in Spain and I store (in Grafana) the readings for humidity and temperature but not pressure (not something I expected to change much in remote Southern Spain). Being Zigbee, the Aqara sensors tend to report mainly when there is a change (not a lot of point in wasting batteries to get repeats of the same data). I have an un-necessarily high number of all kinds of sensor around the house and can check the temperature in both bedrooms, the hall, outside, the living room and my office as well as my outside pergola.
I noted in December that both bedrooms seemed to be quite warm, but given the low heat losses of the building and reasonable temperatures in Southern spain even in late November/early December, I thought nothing more of it – I also had more severe problems due to power outages, one of which blew an internal fuse on teh PXU that charges my Pergola batteries, taking out my beautiful Imou Ranger camera until we got to the bottom of it.
Around Christmas I took a remote look and neither bedroom had shifted from 26c whereas the other sensors around the house were hovering around a more reasonable 10c. That’s when I went into more detail. There is nothing I can do about that until I get back to Spain. I SO now wish I’d added pressure sensing and battery state recording earlier as I took an intense interest in the La Palma volcano but it never occurred to me that there could be significant pressure effects in play so far away.
It was Mat’s article that got me thinking about the subject this evening, but it is worth pointing out that our home in Spain suffers the most attrociously noisy power failures – something like the one we had in the Northeast of England recently but of much shorter duration.
When I get back there as well as doing simple checks, I’m going to add pressure readings and while I’m on, the battery state to my list of stored sensor data in Grafana. I’d just assumed dead sensors for whatever reason but never thought that a significan number of out of the ordinary events could so affect the batteries – time will tell. I’m also planning to replace a single RCB with several RBBOs, cabinet size permitting.
Now I’m onto this general subject, expect updates when future disasters take place as, sadly they will. I’m already convinced the noisy power cut we had in December caused some electrical interference but maybe now I have to think about pressure variation taking out sensors (maybe future variations on the La Palma and Tonga disasters) and how that might come into play. As Mat rightly pointed out, the issues are utterly insignificant compared to the suffering such events cause – but may as well check to see if some sensors are more easily shut down by external influence than others and what those influences might be.
It is worth pointing out that unlike Mat’s setup, my sensors are all fairly new and so in normal use there’s no way those batteries would have given up. It’s unlikely I’ll get any great data now from past events but perhaps some alert on my mobile could let me know about any unusually long period of time with no events from a given sensor.
Hijacking your thread again to warn of a (known) bug in Node-Red…. My lightning detection flow saw a strike less than 10km away a couple of days ago, so I disconnected the router. Result – immediate “fatal error” exception in Node-Red, continually re-starting and crashing. If the websocket node fails to make a connection (ie no internet), it crashes the whole thing, and fortunately writes to the log file. The bug in known on the NR Github, and there are (messy) workarounds. I’ve binned the websocket feed and gone back to the public MQTT feed. To be fair, a websocket connection would normally be established inside an existing http connection. One to watch out for…..
By all means this is as good a place as any to report that thank you – I plan to look into the subject once I get back to Spain at the end of Feb. Must remember I have 2 dead bedroom Zigbee temperature sensors – got to get to the bottom of that. I don’t use the websocket node but others likely do. Oh, public MQTT – if you want an account but don’t want to pay – I’ve hooked up to HIVE – up to 10 clients completely free. Responses up to now are instant – I check in NR which is sending out the messages in the first place – more than I can say for TASKER and the MQTT client plug-in on my Android phone – you ready for this? I have a media response to MQTT incoming from Hive…. “UK front door opening”. What’s wrong with it? It works most of the time but not from phone cold boot despite my best efforts (start up rights, no power-saving economies etc)- and at least once a day it reports in a strong USA accent instead of a British accent. NO idea why.
I have 4 of the Aqara sensors to monitor the humidity in the ground floor part of our holiday home in Spain, and use the results to control extractor fans connected to Shelly smart switches and a dehumidifier attached to a Sonoff. I’ve taken a slightly different approach to the Zigbee connectivity, because my RPI is is a different part of the building, so I use an ESP32 running the SLS Zigbee Gateway code, which is basically a Zigbee to MQTT bridge.
I put new batteries in each sensor when I left in August, and they are reporting battery levels of 86, 80, 75 & 74 percent. The highest of those readings is in a room that has an extractor fan in it, and the device that’s reporting the lowest battery reading is also in a room with an extractor fan.
This doesn’t make much logical sense, as I tend to run both fans simultaneously, so if the fans are causing more frequent changes in temperature or humidity and therefore more frequent readings I would have expected these rooms to have the lowest battery percentage remaining.
Other factors like reported link quality readings don’t seem to correlate to the battery percentages either.
At home in the UK I’ve been testing the Shelly H&T sensors, with the additional USB power module add-ons. As their name implies, they only measure humidity and temperature, so they don’t report pressure. These are WiFi rather than Zigbee devices, and can be configured via their web page to send their data via MQTT. Earlier versions of the firmware allowed you to change how long the device sleeps between waking-up and taking a reading when powered via USB, but the later firmware doesn’t allow that and it’s fixed at every 10 minutes. This is unless the device detects a change o the temperature or humidity before the next scheduled reading is due. The temperature and humidity change thresholds can be changed, with a 0.5 degree C temperature change or 1% humidity change being the minimum values.
For my application, I don’t have any problems powering the devices via USB, and I’d rather have the knowledge that they should continue running even if I’m unable change the batteries for a while. So, next time I’m over in Spain I think I’ll be swapping by Zigbee sensors for these Shelly ones instead (or maybe installing them alongside the existing ones).
BTW, I can recommend a very good Timeout contrib for Node-Red that you could use to trigger a notification if one of your sensors doesn’t send any data through for a while. It’s written by some guy with a Geordie accent, who’s name I can’t quite remember right now 😉
Hah, that would be me 🙂 Good point… didn’t think of that… It seems we follow similar paths – I’m in the UK now and in 4 weeks I’ll be back in Spain -got my residencia etc there now so we’ll be spending the bulk of our time there.
Actually the Timeout node is a really good way to do it….
I put the Zigbee sensors in the bedroom purely as both bedrooms are at extremes of our cavehome and not that many access points.. I’ll have more concrete views when I get back and can find out definitively why the bedroom sensors stopped working.
🙂
What I do is I check every 10 minutes all the entities in my Home Assistant for last updated time. If that was more than certain threshold set (default is 2h) then I get notification. Threshold can be overridden per device and also completely disabled for devices that do not send regular updates. Helps noticing dead sensors immediately.
Hey thanks Martin – I can see some re-thinking coming along when I get back to Spain late Feb… 2 bedroom sensors utterly dead and the onlhy rreason I know that is that they are displaying unreasonably warm temperatures of the range ehen I left there late last year. I definitely should have included timestamps and battery levels somehow in the Grafana info. I don’t know if they are just SHOT or if the events hastened battey demise. All ideas welcome :-). In my case its Node-Red straight to Grafana – and they are the Aqara sensors which are Zigbee and so don’t send regularly, generally only on change.
Battery state is not that useful with these. I have about 15 Aqara temp/hum/pressure sensors in my house. From my experience their behaviour works like this: they report 100% for a long time, maybe a year. Then the batteries start to drop. They do not drop by 1% as one would expect, they drop by 7-11% at a time. So there is no drop and then they drop 10% at once. Fun starts when they get to about 20%. This is the value when they are about to die. They usually start to send a lot of messages at this stage. Like they report values even when there was no change and they do it for 20 minutes straight. Reporting every second. My theory is that the battery is too low and they somehow “reboot” because of low battery but they still manage to send the message so they get to this loop. When this happens, I usually just replace the battery, they would die soon anyway, because all the repeated sending drains the battery quickly. I have another routine in my Node Red where it monitors message frequency per topic per time interval (3 minutes if I remember correctly) and if it is too high, I get notified. That is usually how I find out that my Aqara sensors need battery replacement.
Btw. all my sensors detected, but safely survived Tonga volcano.
Thanks for that Martin – good point about the battery levels – thinking about it I had noticed that they tend to show 100% for a long time.
Here’s the two pressure waves from the Tonga explosion, picked up on a humble BMP680 here in Greece. First to arrive was from the shortest great circle route, second smaller wave came the long way round…. BTW a new addition to sensing here which many be of interest for Spain – having given up on DIY lightning sensors, I’m using Node-Red websocket to get lightning data from Blitzortung.com and identify strikes inside a certain radius from here. We get some scary storms, and I unplug the router as one approaches.
GOOD IDEA. If one knows it’s coming, simply disconnecting everything for a while makes sense. Esy to do if you’er at home, not so easy to disconnect the router for X time if you’re a long sistance away. I guess a double-pole disconnect makes sense as well..
Comments from anyone interested in this subject with thoughts, please??
I’ve tried various lightning sensors, with variable results. I applied for a Blitzortung DIY sensor kit, but I’m number 7000-something in the queue… Firefox developer options showed me the Blitzortung web data comes from ws5 or ws6.blitzortung.org . Connect a Node-red websocket to that and you’ll get a feed of every strike detected by their network. I do a simple bit of filtering by lat/long and anything that occurs inside a certain radius from here sends an MQTT message to the environment displays around the house. Note the timestamp in the messages is in nanoseconds, from a GPS receiver at each sensor. The Blitzortung data is for personal use only. There’s also an MQTT direct feed for Homeassistant users – details at https://github.com/mrk-its/homeassistant-blitzortung. We live opposite a high ridge with wind turbines, and it’s amazing to see the lightning hits they take without damage.
Hey thanks for that Chris – I’ll take a look at that myself when I catch up with my current backlog and things not working etc. 🙂