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.

Log in to reply

Looks like your connection to UniPi.technology Forum was lost, please wait while we try to reconnect.