Java Runtime Environment: which java platform is used and what version
openHAB 3.1.0 - Release Build
I have a slightly complex setup as I use a mixture of Z-wave and RFC switches. I’ve recently installed a load of new z-wave dimmers on most of my lights. I’ve also bought a Vestern 8 button z-wave switch to activate the dimmers. I’ve managed to get associations working to ensure that in the event of a OpenHab failure I can still turn the lights on.
I also use a sitemap to allow control of the lights from a tablet mounted on a wall. So I also have items for the lights so that they can appear on the sitemap.
The issue I have is that when I use the 8 button switch via associations to turn lights on this is not reflected on the sitemap. Is there a way that I can fix this problem so that the sitemap always reflects the state of lighting in the house.
Thanks
Tim
Please post configurations (if applicable):
Items configuration related to the issue
Sitemap configuration related to the issue
Rules code related to the issue
Services configuration related to the issue
If logs where generated please post these here using code fences:
So what you need is to get each light to report to openHAB it’s new state (and who changed it doesn’t matter at all).
That is a problem to solve for each of your mystery switch devices.
Alright, you said there’s a mixture of devices so there is likely to be a mixture of investigatory paths and eventual solutions.
Pick one that doesn’t do what you want. Share details about that. Examine the way that you set it up - why would it report to openHAB at all, when would it report.
Mostly what I want to happen is that when I use an association to turn on a z-wave dimmer (quibino flush dimmer) using a z-wave switch that action is reflected in the state of a Switch Point within openHab so that the sitemap is updated to the new value. I’ll stick with simple ON/OFF for now and look at the complexities of dimmer values later. I guess I could do it via a rule, so that when openHab recieved notification that the dimmer was switched to ON then a rule triggers to set the corresponding Switch Point to on. But if a set the item to on doing this surely it will send another ON to the dimmers which just increases the load on my already crowded z-wave network ?
Let’s go back a step. Ignore who is initiating any change, some external device changes? This external device is linked in some way to an openHAB Item, say via a zwave or RFC channel? And the device fails to automatically report its new state to openHAB?
In common setups, “who dun it” is immaterial - button poking, some other zwave device, or openHAB itself. The zwave device reports its new state to openHAB. There are lots of threads about that not working, invariably due to a messed up association setting on the device itself. Keyword “lifeline”. We can see how that might have happened here.
Pick one device, follow the trail through in detail. I don’t know much about this zwave stuff, but know where you should be looking.
I have to agree with @rossko57 that your issue is probably messed up association.
Basic rules of zwave plus is that the lifeline which is supposed to be group one is always set to the primary controller which would be the zwave controller on openHAB. This would include the lifeline on your vesternet and all of your dimmers.
I can see you can then add your dimmers to the other groups in your vesternet and you are hoping that will then work nicely when openHAB is not there. The problem is that it is very unlikely to give you a nice experience when openHAB is not. When a device can not send reports to the primary controller you will get lags as there will be a lot of retries to contact the controller because devices have no idea it is not available.
I think you would be unlucky to have an openHAB failure and if you have backups and copies of SD cards you could recover very quickly from most eventualities anyway.
I think when you are set your sitemap will be OK when used by the vestenet but the vesternet in openHAB will look out of sync when the light is controlled by other ways. If this matters to you then you would have to write a rule.
Thanks for the help everyone. I’ve kind of sorted it but also believe I’ve found a small bug with the sitemap updating
I have 4 z-wave dimmers behind each wall light in my living room. I have absolutely no wired in wall switches by the way, I rely on z-wave for all my lighting switching in the house using battery operated switches, a choice I made when it was built.
As all the wall dimmers are effectively the same circuit I placed them all under an equipment group called Wall_Lights_Equip. I’ve aggregated them together using average as the aggregation term.
I have an slider on the sitemap with Wall_Lights_Equip as the item. I can use the slider to adjust the brightness of the whole group and it works very well. When I use my 8 button switch with associations to all the dimmers in the equipment that correctly dims the lights as needed and I see the value of the Wall_Lights_Equip item change . However that is not reflected by the slider on the sitemap unless I refresh it. Then I get a message saying I don’t need to refresh a sitemap as it’s automatic !
I have other z-way dimmers also on associations with the 8 button switch and they all work absolutely fine and update the sitemap correctly, so it seems that it’s only when there is a equipment group involved that the refresh is needed.
As for the delay to reacting to a association if openHab is down I’ve tested it and it is minimal. I need this functionality as without it I have no way to turn a light on in the whole house if openHab fails, or as recently happened a series of power cuts destroys the SD Card. (I do have a backup which I have tested )
Items are the one thing you can’t easily get a “code” view of. But it don’t matter much, so far as a sitemap is concerned a Group is a Group and it knows nothing of equipment and points.
Having said that, if you expect the sitemap to display a Group state as a Silder widget position, the Group needs to have a suitable state.
That’s to say, the Group Item needs a sub-type of Dimmer or Color, and a suitable aggregation function like AVG.
View your Item for these details.
Base type and aggregation look sensible.
Next question would be what you use to view the sitemap, some browsers/apps work better than others.
But really you might expect a slider working a Group to jiggle about all over the place. Consider what happens when you issue a command - first one member responds, Group AVG calculates new state while most members in old state. Next member, new AVG, etc. A whole flood of updates.
I wonder if you’d get a better visual effect with the MAX function?
I use the app on my android tablet and also firefox on my linux laptop to view the sitemap. Both exhibit the same behaviour, i.e I have to refresh them to get the slider to move to the correct place. Controlling the dimmers via the slider works fine by the way, but if the dim value is modified elsewhere (associations or whatever) then the slider does not move until the sitemap is refreshed.
To me it seems that a group item updating it’s value is not triggering a sitemap update which is surely a small bug in openHab ?
You’re right, I’ll switch to using MAX so when this is fixed it works better.
Entirely possible, although the bugs in this area were mostly shaken out in OH version 1.
You don’t yet know your Group Item is updating though - confirm in your events.log for changes.
I suspect you will see a big flurry. I’d guess the flood is the root of the issue.
Again, check your events.log to see if the change arrives at the Item correctly.
Note that similar issues reported years ago would be driven away by an openHAB reboot - something to with editing activity breaking the viewer update linkages.
)
