In the 0.0.1 release, if two valves of the same hub are activated/changed at the same time, Hass could deploy two threads: one for each changing value. Unfortunately, the "bits" representation of valves means that the new value is a change to the current value, which means it's possible to read the current value in each thread, make the changes in parallel, and whichever thread sends the update to the OSBee last is the change that "sticks", removing the change to the other valve.
Changes
(key) This PR wraps the change of internal state in a mutex/lock so that only one thread can read/write changed data at a time.
(additional) use a common routine to write the changes back to the OSBee
(additional) reduce log messages to DEBUG to reduce log-chatter
Why?
Fix a race condition updating valves.
In the
0.0.1release, if two valves of the same hub are activated/changed at the same time, Hass could deploy two threads: one for each changing value. Unfortunately, the "bits" representation of valves means that the new value is a change to the current value, which means it's possible to read the current value in each thread, make the changes in parallel, and whichever thread sends the update to the OSBee last is the change that "sticks", removing the change to the other valve.Changes
Config changes
Sadly, no improvement to the sub-optimal config