search

pdmangel / node-red-contrib-openhab2

Other
21 stars 15 forks source link

Input node - on update, but not initial publish #27

Open dakipro opened 6 years ago

dakipro commented 6 years ago

Hi, about the issue https://github.com/pdmangel/node-red-contrib-openhab2/issues/25 it is mentioned that "Channel 1 already outputs only changes, so no need for the 'Item Changed' node." which is very useful feature, however it doesn't always reflect only item change output, as it outputs data each time flow is published as well. Thus making it a bit unpredictable and quite difficult to work with, as the flow is also triggered when it is published, even thought "item" it self is not changed.

For that reason I am always forced to use second channel and complicate flow as mentioned on the linked ticket above, so perhaps a checkbox like "trigger on publish" or "trigger only on item value change" or something like that would be very beneficial. Thanks!

pdmangel commented 6 years ago

But in your solution, how is the last state before publishing persisted ('remembered') ?

dakipro commented 6 years ago

Not sure the answer to your question, states are persisted only in openhab in rrd4j database.

I now tried to reproduce what I described, but I do not manage to pinpoint the reason I decided to always use the second channel. It could be unrelated to the input node itself, its been a while. If I remember correctly, something was triggering update (even if the item didn't update) and that was messing with my rules.

So, if I misunderstood something I guess the issue can be closed

QNimbus commented 5 years ago

If you use any kind of persistence, the items will get an ItemStateEvent from the persistence provider (e.g. rrd4j or InfluxDB) upon restart. I think this is the reason that you might get a Node-Red message even though the item state/value hasn't changed. You can always use the 'RBE' (Report by Exception) node to filter out event without changing the state of the item itself.