I believe you can, if I read the debug log correctly (and see the results 
@chris ?
To be clear though, this should only be required if you donāt want to wait for the wakeup. Itās not however how Z-Wave is designed to work, but if you want to run your system like this, then itās up to you - itās not an issue with the systemā¦
It would be worth checking the log. As I think I said above, HABmin does a sync on startup, so in theory it should be synced unless something is changing the configuration outside of HABmin. If itās not synced, Iād like to see the log during the configuration readback so that we can solve the problem and ensure things are working as they should.
Yes - this is correct. I suggested to also implement this in ESH as well, but it was initially rejected. Something was implemented recently though, so Iāll take another look at this in the medium future to see if it can be added. Itās not normally an issue except with battery devices, but it is very nice to seeā¦
Hmmm - you believe you can what (Iām not sure what this is in reference to - sorry)?
The main reason I hadnāt really mentioned it before is that I donāt have a way to independently verify the config to compare with the binding. Is there some free software I can use to do that? OH is my first foray into ZWave so I donāt really know what other controller software is out there.
did a quick test and no the parameters shown are definately not the right ones.
e.g. for my dch z110 it shows parameter 5 as 0 ā¦ this is for sure incorrect as I can see that it is in test mode ālight blinks when sensor is triggeredā.
did a full oh2 restart before as I think you meant this by āhabmin startupā.
so logs from starting oh2? debug?
. I also observed this before and after some days (maybe also some oh2 restarts; cannot tell for sure) I think the readback took place at some time. though seems a little random
ā¦
how i did it:
I deleted one thing that was already added with changed parameters
added is againā¦ did show ādefault valuesā which (as described above) cannot be
restarted oh2 ā¦ still it shows default instead of correct
Just to explain a little more about how this worksā¦ When the configuration is saved, the configuration is written into the ESH storage. At the same time, the ZWave binding updates the configuration - for mains devices, this all happens quickly, so thereās no problem. However for battery devices (like the Z110 that you mention) this is not the case and there will be a period where they are not synced.
There are two ways we can handle this -:
You update the configuration, the parameter is queued for sending to the device, but the configuration isnāt updated until the device responds. This means weāre synced 
. However, I now suspect that you will be unhappy for another reasonā¦ In this operation, if we start with a value 1, and you set to 2, since the config isnāt updated in ESH, the value you see will change back to 1 until the device responds to say itās changed to 2. This is perfectly reflecting the state of the device, but now the user has no way to know that heās changed anything. This is why in HABmin-1, I had the yellow state which meant āthis parameter has changed, but itās not yet confirmed, so itās unsyncedā.
The other option is what we have - you make the change and ESH is updated so the user thinks that the device is updated. However in the case of a battery device, this update might not happen for another 24 hours (depending on the wakeup interval) so the configuration will remain unsynced for that period. Again, in HABmin-1 this would be displayed with the yellow background for 24 hoursā¦
I chose option 2 here because I can imagine that in option 1, people will tell me that it doesnāt work at all as the UI would keep changing back each time you changed it!
What do you think? Which option is best (I know - you probably tell me option 3, which is what HABmin-1 did 
).
Some new features were added to ESH recently that I might be able to use to improve this.
Yes please.
ok will do a log asap 
yes like habmin1 was best because it was just a clear state for the user. however also some help texts in habmin2 would help to understand stuff like this
so talking about wakeup intervall ā¦ its not enough that the device is talking to oh2 (like sensor updates on temp and stuff)? wakeup intervall is something different?
but to be honest there are other things in zwave2 that trouble me more
-
non persitent item states ā¦ this issue applies for all Motion / Door / Window alarms
-
sensor binary for door / window / motion devices reports as On Off and no way to change it
-
when i change door/window sensors from āswitchā to ācontactā the log does not show an update of that sensor at allā¦ however the odd thing: still it updateds on / off on the UI when I open / close that door (magic?) ā¦ so I can ignore that issue
its just strange
No - wakeup is different (I think this is detailed on the Z-Wave wiki, but I will try and find some time to write some more information about how things work at some stage). Basically though, the wakeup is sent periodically, and openHAB can only send request TO the device when it receives the wakeup since the wakeup notification tells OH that the device can now RECEIVE for the next few seconds.
- Iāll look at the update of states when I get a chance.
- On/Off status was based on the definitions in ESH. As per another discussion, I can now ignore these and it looks like in the future there might be more chance to improve this. However, as stated in the thread you reference, ESH should already show open/closed if the translations that are in the binding work correctly (but this is nothing to do with the binding so I donāt think I can do too much).
- As stated elsewhere, ESH currently does not allow you to change the item type - really - donāt try - it doesnāt work! If you set an item that is not consistent with how the binding is providing the data, then you will not get any data. Thereās no way around this in the current ESH so please just donāt try. You might think you can set it since the UI allows items to be set to anything, but if itās not what the binding has already defined, then itās not going to work - sorry.
thanks !!!
I opened an issue for ESHā¦ lets see what happens
ahh thats new to me ā¦ didnāt read that somewhere. just read the confirmation from Kai that Door / Windows should be contact and just switched in in habminā¦ very tempting drop down menu
good to know
Where? I canāt see it. Iām interested in what youāre actually requesting?
Ok - it was discussed between me and Kai in the thread you referenced above (about mapping).
oops you are rightā¦ closed it at the wrong place and copy / pasted here:
well I guess I donāt understand everything the pros say
No probs 
.
Iāve now added a new channel type so you can have a contact type if you update the device in the database .
No worries, I meant you can see in de debug log if pending changes are pushed to the zwave device. When I was testing this I never waited on the wakeup, but pushed the button and checked the log. Sometimes several clicks where necessary I onder for the zw100 to wake up and receive the new conf parameters.
mhh
updated binding
removed z110
ā does not show up again in discovery
EDIT !! DID NOW SHOW UP. JUST TOOK LONGER ā¦ NORMALLY THEY COME INSTANTLY AS THEY ARE STILL BOUND TO THE ZWAVE STICK.
No - thatās not correct. Iāve said somewhere that they only show up after the initial discovery is done - basically after the manufacturer information is known. For a battery device, this will take time unless you wake it up manuallyā¦
I did send you a PM with a link for a full startup log of my OH2
e.g. NODE 11 definately has different parameters then shown in habmin2 after āreadbackā
Thereās no node 11 initialisation during the log you sent. I guess itās a battery device, and itās not woken up. In this case, OH will show the value you last set, but this might not be the same as the binding set (if that makes sense)ā¦
If you set a value, but the device doesnāt wake up, then the OH version of the config will show the value you set, but if the device hasnāt woken up, then it wonāt have been transmitted to the device - so they will be out of sync if you restart OH at this timeā¦
Iām not saying that is the issue, but since the device hasnāt woken up, I dont really know whatās going onā¦
Well OK i will try to wake it up during Startup.
However i Set wakeup intervall on few minutes for that Device but itās not being updated to the current/correct parameters in habmin2 for at least 2 days now.
Readback takes place on startup or any Wakeup right?
It is performed on all devices when the binding starts. For mains powered devices, this happens straight away - for battery devices, it will happen after the device wakes up next.
regarding this topic:
When I look on the default āHOMEā Sitemap in Habmin2 ā¦ the values do show āpersistentā.
When I copy the Items from the āChannelsā on the sitemap that problem occurs.
Can you tell me how the HOME thing is populated and how can I e.g. see the item name used for an entry there?
Sorry - I donāt understand what you mean by this?
Sorry, I donāt know - itās generated within ESH or OH - Iām not sure though as Iāve not tried to find it.