I have several Homematic IP Items connected via Homematic CCU2 and openHAB 2 binding.
Everything worked well for several months
Now I have three of six devices that don’t get any updates from the CCU - or don’t react to updates any more.
E.g. a temperature sensor that’s flat for several days. Updates are propagated from the sensor to the CCU and visible in the WebGUI there. But the updates get lost from CCU to openHAB.
The other three are fine…
There is nothing in openhab.log (Really, not even mentioning anything from homematic for weeks)
Do you have an idea where to look? I’m about to install everything new, but really would like to know what’s going on to prevent that happen again.
Thanks for any hint
I have no experience with HmIP stuff, but you could check the devices via the REST API. Are differences between the working and non-working sensors?
thanks for the hint. I haven’t thought about it. But actually the info was the same as on the WebGUI e.g. BasicUI.
Meanwhile I’ve removed and added the Things again and it is working again.
But… still no ideas what when wrong.
I will install a rule that searches for items not updated for e.g. 24h and sent a warning.
Not nice, but my best guess here.
Use the expire binding, add these items to a
<group> and create a rule when Member of
<group> changes to null. Let openHAB do the searching.
I have never worked with expire binding. Interesting, but seems to be dangerous, right? I guess the possible sideeffects might be … challenging?
But how do you do a rule that gets an event when a member of a group have been updated?
I’ve searched for that and haven’t find it … possible a specific keyword?
Thanks for taking care…
rule "check for undef"
Member of gMyGroup changed to UNDEF
var String msg = String::format("*Offline* = %s\n", triggeringItem.name)
triggeringItem was the most important change in openHAB 2.2,
Member of is the most important change in openHAB 2.3.
This is at least my opinion. I got rid of hundreds of lines of code.
Yes! You don’t need to define the same logic twice: Group and a rule containing all items of the very same items again.
So this works in 2.3? I’ll have to check.
Yes, with 2.2 you needed to extend the trigger with each item, but the rule itself was the same.
Item item1 changed to UNDEF or
Item item2 changed to UNDEF or
Item item3 changed to UNDEF or ...
How does the item change to UNDEF? I have a situation where some sensors stop sending temperature and pressure updates every now and then. I have a field that updates to show the date and time the last status was received but recently I realised that one of the sensors hadn’t updated in 10 days and I did not realise and wanted to create a rule that would send me notification if the status does not update for a while.
You can use the expire binding to cause it to go to UNDEF after your desired timeout period. Then you can have a rule to check for UNDEF.
With the expire binding. It’s all above your post.
first of all, I have the same Problem at different divices at different Locations.
So it seams to be an generall problem?!
Now, my question to the conversion at the beginning:
Am I right? With this solution you will find out that one item is UNDEF but you will do no more actions?
How can the general Problem be solved?
In my case, the item is still up to date in the ccu2 but openhab has still an old value.
This problem is only with homematic IP devices.
Sometimes I am going to restart the Openhab server or / and the CCU2.
If someone has any ideas, will it be great!