Disappearing devices

I had a power failure at my house.
Vera is on the UPS, so it did work for the whole time, but Netatmo base station was down, as well as the router (it has some UPS as well, but it run out of power and for couple of hours system was without net connection).
When the power returned and devices recovered, I’ve found that part of my devices are missing. For example I have only part of measures from the base station (like I have humidity but temperature is missing), don’t have data from rain or wind sensor, etc.
It was cleared after forcing luup reload, but now I have new devices in the place of missing ones, with new ID’s, default names, so my scenes referring to these sensors are broken.

I didn’t have such cases before last updates of the plugin, even if power failures happened from time to time. I had some cases when one or two sensors were re-created from whatever reason (fortunately never the important ones), but it was never the case that more than half of the sensors are reset.

Is there a way to avoid such effects after a power failures? I know I can put my Netatmo on UPS too, but that’s not a complete fix, as UPS also will run out of power after some time.

Yes, this has been noted before. It seemed to arise from a change of functionality in the Netatmo API itself. If the plugin doesn’t receive data on a module or sensor when it starts up, then that child device is removed. If it subsequently appears again a new one (with a new device ID) is created.

Getting around this problem would take a significant rework of the plugin initialisation, which is on the list to do anyway since I’m keen to remove the login username and password from the device variables - but it won’t happen any time very soon.

Hi Ak,

Can I suggest that the plugin creates all devices configured whether the data (ever) gets returned or not. That way the device numbers remain. I have not looked at your code is that is a simple change or not.

Cheers Rene

Yes, that’s the obvious change – I think we’ve even discussed that before somewhere on this forum.

I just need to do it!

Sorry for long time without reply - yes, I know that this happen sometimes, but in my setup it never occured on such a huge scale (about half of my devices were re-created), and never on the most basic sensors (i.e. temp, humidity). I had CO2 recreated from time to time, or noise sensor. But the temp/humidity (which I use in my scenes) were pretty stable. This is why I was wondering if recent update did something in addition.

It is a big problem, since recent firmware updates, and the plugin needs a whole rewrite.

I suffer the same issues as you but mitigate them by not using child devices for scenes but, instead, simply use the variables which are all in the main plugin device. Note, though, that these are raw measurement values, in SI units, so if you’re wanting imperial then you’ll have to convert the units yourself in a scene.

I am busy with other developments, but in fact what I’m currently doing will help in the rewrite of Netatmo when I get around to it.

Good advice, thanks!
Fortunately for me, I’m in the “SI zone” and don’t need calculating imperials

I have also been affected byt this issue lately, I will now take note of the device ID so I can change them back the next time this happens because it is a lot more work to dig through and correct automation logic when device ID changes.

Yes, I really must get around to fixing this.

2 Likes

Is there any easy way to move Vera multiple devices into a room in one go?

My Netatmo locked up overnight and now all the child devices have re-spawned in “no room”. :frowning:

Thankfully all my automation now points to the parent Netatmo device, so that didnt break this time.

I just had a hopefully good idea which would be a great interim solution, re-spawn the child devices into either A/ user specified room or B/ the same room that the parent device is in.

This would at least make things less painful when you have a stack of devices go missing and then respawn. As mine did today for a second time due to my wifi going belly up.

@dJOS in my opinion there should be a possibility in the Netatmo plugin to disable the function that checks for new devices in the weather station. This way they will not get deleted and recreated.

@akbooer has already mentioned they re-spawn with different device IDs in the Netatmo API.

OK folks. It’s definitely time I fixed this. My only difficulty is stopping myself from making other changes that I know I’ll want to do. It’s entirely bound up with the way that Vera/Luup handles device children, so it needs a work-around of some sort.

1 Like

OK, so v20.5.11 in the development branch has a ‘quick fix’ (I hope) for the missing module/device problem.

I did a test by removing a battery from an additional module, power cycled the Netatmo base station and reloaded openLuup. The log shows that the missing module sensor devices have been identified but recreated as plugin child devices anyway.

2020-05-11 14:50:51.546   luup_log:305: Netatmo: device '[309]GardenRoom - CO2' not found in current list of modules
2020-05-11 14:50:51.546   luup.chdev.append:: [03:00:00:01:f9:32-CO2] GardenRoom - CO2
2020-05-11 14:50:51.546   luup_log:305: Netatmo: device '[311]GardenRoom - Temperature' not found in current list of modules
2020-05-11 14:50:51.546   luup.chdev.append:: [03:00:00:01:f9:32-Temperature] GardenRoom - Temperature
2020-05-11 14:50:51.546   luup_log:305: Netatmo: device '[310]GardenRoom - Humidity' not found in current list of modules
2020-05-11 14:50:51.546   luup.chdev.append:: [03:00:00:01:f9:32-Humidity] GardenRoom - Humidity
2020-05-11 14:50:51.546   luup.chdev.sync:: [305] Netatmo Mac, syncing children

and the devices page shows that the child devices are still there, although, obviously the metrics are flat-lined (you can see that the CO2 sensor hasn’t had its icon updated.)

Reinstalling the battery, power cycling the base station, and restarting openLuup shows a normal startup log for the plugin:

2020-05-11 15:02:00.826   luup_log:305: Netatmo: creating child devices...
2020-05-11 15:02:00.826   luup.chdev.append:: [03:00:00:00:34:ba-CO2] Guest - CO2
2020-05-11 15:02:00.826   luup.chdev.append:: [03:00:00:00:34:ba-Humidity] Guest - Humidity
2020-05-11 15:02:00.826   luup.chdev.append:: [03:00:00:00:34:ba-Temperature] Guest - Temperature
2020-05-11 15:02:00.826   luup.chdev.append:: [03:00:00:01:f9:32-CO2] GardenRoom - CO2
2020-05-11 15:02:00.826   luup.chdev.append:: [03:00:00:01:f9:32-Humidity] GardenRoom - Humidity
2020-05-11 15:02:00.826   luup.chdev.append:: [03:00:00:01:f9:32-Temperature] GardenRoom - Temperature
2020-05-11 15:02:00.826   luup.chdev.append:: [70:ee:50:01:55:06-CO2] Indoor - CO2
2020-05-11 15:02:00.826   luup.chdev.append:: [70:ee:50:01:55:06-Humidity] Indoor - Humidity
2020-05-11 15:02:00.826   luup.chdev.append:: [70:ee:50:01:55:06-Noise] Indoor - Noise
2020-05-11 15:02:00.826   luup.chdev.append:: [70:ee:50:01:55:06-Pressure] Indoor - Pressure
2020-05-11 15:02:00.826   luup.chdev.append:: [70:ee:50:01:55:06-Temperature] Indoor - Temperature
2020-05-11 15:02:00.826   luup.chdev.append:: [02:00:00:01:4c:2c-Humidity] Outdoor - Humidity
2020-05-11 15:02:00.826   luup.chdev.append:: [02:00:00:01:4c:2c-Temperature] Outdoor - Temperature
2020-05-11 15:02:00.826   luup.chdev.append:: [70:ee:50:01:60:e2-CO2] Studio - CO2
2020-05-11 15:02:00.826   luup.chdev.append:: [70:ee:50:01:60:e2-Humidity] Studio - Humidity
2020-05-11 15:02:00.826   luup.chdev.append:: [70:ee:50:01:60:e2-Noise] Studio - Noise
2020-05-11 15:02:00.826   luup.chdev.append:: [70:ee:50:01:60:e2-Pressure] Studio - Pressure
2020-05-11 15:02:00.826   luup.chdev.append:: [70:ee:50:01:60:e2-Temperature] Studio - Temperature
2020-05-11 15:02:00.826   luup.chdev.append:: [05:00:00:00:0b:ba-Rain] Rain - Rain
2020-05-11 15:02:00.826   luup.chdev.append:: [02:00:00:01:55:f2-Humidity] Garage - Humidity
2020-05-11 15:02:00.826   luup.chdev.append:: [02:00:00:01:55:f2-Temperature] Garage - Temperature
2020-05-11 15:02:00.826   luup.chdev.sync:: [305] Netatmo Mac, syncing children

and normal operation of the device is restored (and, crucially, the device numbers have been retained)…

So, within that limited test, all looks to be working as expected.

In an ideal world, I would flag the devices with a status that shows that they’ve failed, so that it’s more obvious from the devices page. I also don’t know for sure that there are any unexpected side-effects, so I’d like to enlist you all to try this out and report any problems (I’m sure you will.)

If this does fix the problem for you, then I can only offer my apologies that it has taken so long. If it doesn’t, then I’ll offer them for being so inept as to be unable to fix it at first attempt.

Good luck

AK


Edit: I should add that all the testing I have done has been under openLuup (as you can see from the above screen shots.) I’ve not tried this on Vera, but very much hoping that it works the same way!

2 Likes

I’m not sure under ALTUi, but under Vera luup.device_message can be useful to communicate. Maybe you can add it to the wonderful openluup console :wink:

Yes, it wasn’t that I didn’t know how to do it, it was just that I haven’t done it (until I know that the fix works.)

luup.device_message() works and is used widely in the ZWay openLuup plugin to flag failed devices.

On the openLuup console it just colours the device title banner:

…but in AltUI you get the message as well:

2 Likes

Cheers, just manually updated - thanks Rene. :sunglasses:

Best Home Automation shopping experience. Shop at getvera!

© 2020 Vera Control Ltd., All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules