FWIW my parameter 5 is on ‘Send Sensor Binary Report CC’.
Also it is my experience, that then you change configuration parameters, you really have to press the little button on the back a couple of times, and watch the debug log closely to verify the changes are persisted. And this way you don’t have to wait for w wakeup.
That seems to be my anecdotal experience too. I was sure I set the sensitivity for the PIR down to 3 (and it at least seems less sensitive than when it came out the box as 5) but HABmin shows it as 5.
In habmin1 the setting actually was marked yellow until successfully commited. At least I think so.
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.
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?