Remove dimmer polling#183
Conversation
|
any way I can get you to test something for me. I do completely understand the whole excessive network traffic thing. We want to minimize it as much as possible but acuracy is also of great importance. if you can give the test code a go and see if it minimizes the traffic then this may be a good approach. This is going to check if the switch supports target_level. if it does and the target level matches the new value then there is no need to send a refresh to openzwave. if it does not match then add the timer. and also add the timer if the switch does not support it. and only add a single timer. no need to add 2 refreshes. def set_dimmer(self, value_id, value):
"""
The command 0x26 (COMMAND_CLASS_SWITCH_MULTILEVEL) of this node.
Set switch to value (using value value_id).
:param value_id: The value to retrieve state
:type value_id: int
:param value: The level : a value between 0-99 or 255. 255 set the level to the last value. \
0 turn the dimmer off
:type value: int
"""
logger.debug(u"set_dimmer Level:%s", value)
if value_id in self.get_dimmers():
if 99 < value < 255:
value = 99
elif value < 0:
value = 0
self.values[value_id].data = value
# Dimmers doesn't return the good level.
# Add a Timer to refresh the value
for val in self.values.values():
if val.command_class == 0x26 and val.index == 9:
if val.data != value:
timer1 = Timer(1, self.values[value_id].refresh)
timer1.start()
break
else:
timer1 = Timer(1, self.values[value_id].refresh)
timer1.start()
return True
return False |
36af6a2 to
d2f8a92
Compare
|
I see you have added the code above. did it work?? |
|
It works, as in it does exactly what I expect, but not what I want. This library is only compatible with the 1.4 OZW release which doesn't expose Target Level, so the condition will never be met; this results in an extra poll. In the log below you see it does a set, then immediate get and receives 88 (ramping down from 99), this is standard OpenZWave behavior. It then fires the timer and gets another intermediate value of 51 which is this library's timer. This would be the "final" state, and it would be inaccurate. I have an application level timer that is aware of my configured "ramp time" so it will actually wait long enough before polling and you see it gets an accurate 0, and toggles my UI accordingly. I feel strongly the polling here is the wrong place, the library does not have enough data to understand how long to wait, 1 second is just an arbitrary guess. It's also inconsistent that we do this when setting Value to 0 (off), but not when setting it to 99 (on), if it is truly useful we should do it on both "sides." |
|
Log the proposed code that removes timers entirely. |
d2f8a92 to
ce5f665
Compare
|
If you build python-openzwave using the --flavor=dev switch then it should build using the 1.6.X code. which would expose that value, I may be wrong tho. I would have to go and check. How are you running your tests? or you using python-openzwave in an application? or running it from a script?.... |
|
Home Assistant. |
|
|
|
yeah yeah I'm awake and working on python-openzwave. There is someone doing the HASS side of things to get the new python-openzwave installed and running. we are also getting rid of many bugs in python-openzwave and openzwave alike. And that whole thing with doing a value refresh has been removed in the new version. here is an invite link if you either want to test or want to chime in on any development aspects |
|
Woo! I'd much rather have time spent on the "big" upgrade, I'll just maintain my patch independently and try to make some time to test the new things. |
|
I thought you might like that. we are working on getting this going. |
Wait, am I going crazy or is this still in? python-openzwave/src-api/openzwave/command.py Line 609 in 8be4c07 |
Remove superfluous dimmer polling. Application should schedule its own timer or utilize Target Value or SetChangeVerified.
See discussion on #160 .