Recommended AND function doesn’t get "always" evaluated correctly on boot

English
1

Hello,

In this example I have a pair of two modules:

  • VMBPIRO – mounted outside
  • VMB1RYNOS – acting as a control for a contactor

This contactor then turns on or off the heating for rain… whatever those ducts that go downwards are called in order to avoid ice formation within. The goal for the moment is to only enable heating between -2.5°C and 2.5°C. As I can set up the alarms for high and low temperatures almost arbitrarily, I have chosen to set them up as such:

Low Alarm = 2.5°C
High Alarm = -2.5°C

This way, the two alarms will only ever be in a Pressed state at the same time between the temperatures I want to enable heating for. Then following the FAQ: How do I realize logical and advanced functions in velbus? I set up:

  • VMBPIRO.Low Alarm o--[ 703. Inhibit while initiator is open ]--> VMB1RYNOS.CH1
  • VMBPIRO.High Alarm o--[ 104. Momentary (follow) ]--> VMB1RYNOS.CH1

This seems to work alright, if all pieces fall into order. Alas, it seems that the state is not correctly computed when modules boot for the first time if this happens while the temperature is higher than 2.5°C! In this situation the High alarm will switch from Released to Pressed on boot and the VMB1RYNOS.CH1 will follow, but the Low alarm will remain in its initial state of Released and thus the 702 action will not get applied!

Is this the expected behaviour with the Inhibit while initiator is open on a fresh boot? If so, is there a better way to implement a Logic AND that would correctly propagate the state on a fresh system boot up? Neither of the two modules have any outstanding firmware updates I could apply.

2

NB: for this specific example, I can set up Low Alarm = -2.5°C, High Alarm = 2.5°C (i.e. reversing the settings from the original, so that neither of the alarms is “Pressed” in the desired temperature range) and then using NOT(VMBPIRO.Low Alarm || VMBPIRO.High Alarm) instead, which I believe works correctly on a fresh boot situation, at a cost of an extra virtual relay (or two if I want to have this extensible and comprehensible). But I guess my question is about alternatives for the correctly working AND function in general, as I anticipate hitting this sort of bug more often as I make my lights… fancier.

3

Hi

I have two initial thoughts.

1, Why do you want it to switch off below -2° ?

2, that’s overly complicated.

If you have a reason for #1, I’ll try to help find a solution.

If not, I can suggest an easier set of actions.

4

Hey,

1, Why do you want it to switch off below -2° ?

Well, so to understand this, let me explain why this waste of energy (and it is hard to call resistive rain gutter anything else than that) exists at all. Somewhere around 0°C rainwater tends to start becoming an ice, and in rain gutters especially, there can be a constant supply of water that’s about to freeze solid. This can lead to rain gutters getting clogged shut (bad), and then to the pipes breaking as the rest of the rainwater stuck inside undergoes a phase change and expands in volume. This is the only reason these heaters get installed at all. At some point though, rain stops being a concern. At lower temperatures, snow is already a solid form of water and even if enough of it makes into the pipes to clog it, phase change, expansion and pipes breaking is no longer a concern. And, well, why waste precious watts on heating the winter outside :wink:

(I’m not exactly sure if -2.5°C is the correct threshold, but this sort of logic is pretty much the state of art in gutter heating and seems sound enough to me. That said, I wonder if they haven’t heard of water or moisture sensors? I’m adding some of that to this logic at some point down the line for sure…)

2, that’s overly complicated.

Sorry to ask a clarification, but “that’s” being what? Is it (1) my use of alarms on VMBPIRO to implement this; (2) my idea to use the AND logic due to (1); or (3) my implementation of the AND logic function; or (4) my current solution to use NOT(x OR y) logic and its implementation as the alternative?

Addendum: How I’ve implemented the NOT(VMBPIRO.Low Alarm || VMBPIRO.High Alarm)?

I realize I didn’t write my current solution down, so here goes in case anybody else finds this useful. This is largely just an application of the ideas from the FAQ document I linked above and the De Morgan’s law:

  1. VMB1RYNOS.CH2 o-[ 406. Trigger on release timer (Continuous) ]-> VMB1RYNOS.CH1
  2. VMB1RYNOS.CH3 o-[ 102. Off ]-> VMB1RYNOS.CH1
  3. VMB1RYNOS.CH2 o-[ 412. Restartable Timer (1s) ]-> VMB1RYNOS.CH3
  4. VMBPIRO.Low_Alarm o-[ 104. Momentary (follow) ]-> VMB1RYNOS.CH2
  5. VMBPIRO.High_Alarm o-[ 104. Momentary (follow) ]-> VMB1RYNOS.CH2
  6. Configured Low Alarm = -2.5°C and High Alarm = 2.5°C

Here VMB1RYNOS.CH2 represents not(freeze risk) and VMB1RYNOS.CH3 is used in implementing the timer based NOT logic function.

All in all, I’m reasonably happy with the NOT(x OR y) solution at this point in time, and my overarching intent in creating this topic is more about pointing out a potential issue in the recommended implementation of the AND logic (with the rain gutter heating as a motivating use-case for having it work correctly on installation’s boot-up.) If I’m missing an obvious simplification, I’ll gladly take it, though.

5

That makes perfect sense now.