Unipi relay switching and then switching back immediately when Pimatic rule triggers
-
Hi, I am using UniPi with Evok and Pimatic. I use the board to control my heating and I am quite happy with it, it's really working in a big way.
Now, I did come across an issue when I tried to improve my Pimatic rules. I observe a strange behaviour which consists in a relay switching as according to my rule but then immediately switching back, although (I believe) there is no rule that should trigger such an action. I have observed this on several occasions, although I don't think that the effect can be reliably reproduced. I wonder if this is related to varying response times from the Unipi board which is connected via the Evok web service running on the Pi. When I switch logging on for Pimatic's unipi-evok plugin, then this situation shows as follows:
10:49:53.738 [pimatic-unipi-evok] debug: [UniPiTemperature#speicher] status update: { interval: 15, 10:49:53.738 [pimatic-unipi-evok] debug:> value: 60.05, 10:49:53.738 [pimatic-unipi-evok] debug:> circuit: '28FF2179B51605B6', 10:49:53.738 [pimatic-unipi-evok] debug:> address: '28FF2179B51605B6', 10:49:53.738 [pimatic-unipi-evok] debug:> time: 1515923393.731506, 10:49:53.738 [pimatic-unipi-evok] debug:> typ: 'DS18B20', 10:49:53.738 [pimatic-unipi-evok] debug:> lost: false, 10:49:53.738 [pimatic-unipi-evok] debug:> dev: 'temp' } 10:49:53.766 [pimatic-unipi-evok] debug: [UniPiRelay#pumpe-laden-warmwasser] state change requested to: false 10:49:53.834 [pimatic-unipi-evok] debug: [UniPiRelay#pumpe-vorlauf-heizung] state change requested to: true 10:49:53.892 [pimatic-unipi-evok] debug: [UniPiRelay#brenner] state change requested to: false 10:49:53.974 [pimatic] info: rule set-state-off: set $operation-state to off 10:49:54.019 [pimatic-unipi-evok] debug: [UniPiRelay#brenner] state changed to: false 10:49:54.024 [pimatic] info: rule set-state-off: turned Brenner off 10:49:54.040 [pimatic-unipi-evok] debug: [UniPiRelay#pumpe-laden-warmwasser] state changed to: false 10:49:54.046 [pimatic] info: rule set-state-off: turned Pumpe Laden Warmwasser off 10:49:54.072 [pimatic-unipi-evok] debug: [UniPiRelay#pumpe-vorlauf-heizung] state changed to: true 10:49:54.077 [pimatic] info: rule set-state-off: turned Pumpe Vorlauf Heizung on 10:49:54.092 [pimatic-unipi-evok] debug: [UniPiUpdateManager] received update: {"value": 0, "pending": false, "circuit": "3", "dev": "relay", "glob_dev_id": 0} 10:49:54.098 [pimatic-unipi-evok] debug: [UniPiRelay#pumpe-laden-warmwasser] status update: { value: 0, 10:49:54.098 [pimatic-unipi-evok] debug:> pending: false, 10:49:54.098 [pimatic-unipi-evok] debug:> circuit: '3', 10:49:54.098 [pimatic-unipi-evok] debug:> dev: 'relay', 10:49:54.098 [pimatic-unipi-evok] debug:> glob_dev_id: 0 } 10:49:54.101 [pimatic-unipi-evok] debug: [UniPiUpdateManager] received update: {"value": 1, "pending": false, "circuit": "2", "dev": "relay", "glob_dev_id": 0} 10:49:54.105 [pimatic-unipi-evok] debug: [UniPiRelay#pumpe-vorlauf-heizung] status update: { value: 1, 10:49:54.105 [pimatic-unipi-evok] debug:> pending: false, 10:49:54.105 [pimatic-unipi-evok] debug:> circuit: '2', 10:49:54.105 [pimatic-unipi-evok] debug:> dev: 'relay', 10:49:54.105 [pimatic-unipi-evok] debug:> glob_dev_id: 0 } 10:49:54.108 [pimatic-unipi-evok] debug: [UniPiUpdateManager] received update: {"value": 1, "pending": false, "circuit": "3", "dev": "relay", "glob_dev_id": 0} 10:49:54.118 [pimatic-unipi-evok] debug: [UniPiRelay#pumpe-laden-warmwasser] status update: { value: 1, 10:49:54.118 [pimatic-unipi-evok] debug:> pending: false, 10:49:54.118 [pimatic-unipi-evok] debug:> circuit: '3', 10:49:54.118 [pimatic-unipi-evok] debug:> dev: 'relay', 10:49:54.118 [pimatic-unipi-evok] debug:> glob_dev_id: 0 }Could it be that this is really something to do with the Evok subsystem? It looks like for some timing or latency issue the state change request is overtaken by a state update and then lost. In the example above, everything looks good until 10:49:54.108 when UniPiUpdateManager suddenly reports that the relay at circuit 3 has a value of 1 again.
For the files: I am on Release candidate 2.0a. If it helps, I upgrade to 2.0.1.
Edit: The rule "improvement" that I have tried in Pimatic implied rules that trigger various actions at once, like so:
{ "id": "set-state-off", "name": "set-state-off", "rule": "when [$operation-mode = \"hot-water\" and $speicher.temperature > ($clipTemperatureHotWaterBottom + $clipTemperatureHotWaterOffset)] or [$operation-mode = \"heating-with-hot-water\" and $heizung-vorlauf.temperature > ($clipTemperatureBottom + $clipTemperatureOffset) and $speicher.temperature > ($clipTemperatureHotWaterBottom + $clipTemperatureHotWaterOffset)] then set $operation-state to \"off\" and turn brenner off and turn pumpe-vorlauf-heizung on and turn pumpe-laden-warmwasser off", "active": true, "logging": true }This rule would set a variable (operation-state) which is internal to Pimatic, but also 3 relays (brenner, pumpe-vorlauf-heizung, and pumpe-laden-warmwasser). I wonder if it is this what causes the problem. However, I do think that it should be possible to issue several state change requests at once and have them handled, since switching one pump on and another off is not so uncommon a situation.
-
I think this is caused by internal state caching, as the state update takes some time to propagate and be read back. This is an issue we constantly face with Mervis, but in practice is true for all asynchronous communication with the device. Is it possible that the physical real state is at odds with what you get back from EVOK?
If that is indeed what is happening, then unfortunately there isn't much we could do, besides using a write-back cache for relays. Which potentially could cause desynchronisation issues further down the line.