That’s an interesting idea and I tried to explore it more.
While RBE node
does not provide a way of publishing the old
value, I made my own mechanism:
So, if a proper MQTT message is published, the flow directs the value of the AC fan mode to the function node
:
[1]
var old_mode=context.get('old_mode') || ''
//node.warn(old_mode);
if (old_mode != ""){
if(msg.payload != old_mode){
msg['old_mode'] = old_mode;
//node.warn(msg.payload);
}
}
context.set('old_mode', msg.payload);
return msg;
… tl;dr, if the mode
value differs from the previous one, the old one is attached to the old_mode
property of the msg
object.
The next node
in the flow is a switch that simply checks for the existence of this property and contains 2 identical switch cases to split flow in 2 for such case:
[2]
The first one replaces payload by the msg.old_mode
and forwards the value to the V44 write
node
[3]
whereas the second one uses the new mode
value and writes it to the same pin after some delay.
(note that i used completely different pin for this to be used just by the superchart widget, as the original pin might cause some loops as there are some write_event
nodes attached to it).
This flow ensures that 2 consequent values are written on a state change with a really small delay between them.
And it works reasonably well …for the live
data granularity:
but unfortunately not that well for the others (e.g. 30mins
):
.
I also tried to put varying delays to the flow without any effect. I guess with the minimum resolution of 1 minute, I might put in 1 minute delay, but that would cause some race conditions on multiple value changes inside that time window.
Anyway, I’ve learned a lot during this experiment so I don’t regret anything.