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.