<Solved> Qk Match OpenHAB UI Switch to Node-Generated state

[papa]

        I worked out the following approach to address this issue:

     Using only the first item below to change & report the state of (DHT End Node) node 2's device 16...
if one clicks the node's virtual switch on the browser user interface (UI), the switch toggles (quickly) an ON or OFF state & a LED or relay on the node also toggles.

        HOWEVER, IF ON THE NODE ITSELF, someone presses the push button, the UI switch never changes to show the true state of the node. I was troubled by this last situation that looking at the UI, I could not be sure of device 16's state (LED or relay or ??).

I'm not sure the following approach is the best way, but the only one I could work out (back when I was learning OH) without throwing errors & greater delays.

        This approach uses two items:
Switch Act_Node02 {mqtt=">[mosquitto:home/rfm_gw/sb/node02/dev16:command:ON:ON],>[mosquitto:home/rfm_gw/sb/node02/dev16:command:OFF:OFF]"}
       
Switch Node02_Output { mqtt="<[mosquitto:home/rfm_gw/nb/node02/dev16:state:default]" }

Both items use the node's device 16. The first item toggles device 16 & the other READS the device 16 state.

    It also uses a rule:
rule Match_UI_&_Act_Node02
    when
        Item Node02_Output changed
    then
        if(Node02_Output.state==ON) {
            postUpdate(Act_Node02, ON) }
        if(Node02_Output.state==OFF) {
            postUpdate(Act_Node02, OFF) }
end

The rule uses the second item's READ to postUpdate the first item's state AND thus the appearance of the UI switch.
     Hence it's called Match_UI_&_Act_Node02

     Finally it uses a sitemap entry:
Switch item=Act_Node02 label="Node02_Output"

This approach makes sure the UI switch's appearance shows a press of the node's physical push button.
      For me, this was a great improvement in reliability of what's seen on the UI.

It works, with some delay, maybe because (necessarily) more is involved or maybe because I unnecessarily complicated things.
When using rules in other situations (especially including postUpdate), such approaches seems to take longer to show effect.

    [To Be Continued below]

[papa]

On 2/14/2016 in the Re-imagined RFM node code... thread I posted the above (with some editing differences).

Since then, I've re-considered the "delay" of various lengths & other possible approaches to addressing the issue &/or reducing the delay.

First, one notices the delay only when one has the node in the same space as the User Interface (UI). Press the physical push button on the node & count how long before the Node's virtual switch changes appearance on the UI, seems like 5 to 17 seconds.   If node & UI are not close, the delay probably won't matter.

How about another way to address the issue (so pressing a node push button shows on the UI)?

          In this OpenHAB Community thread, in Oct '15, rlkoshak talked about:

binding one switch to two different bindings. Not all bindings support this and the behavior is not always as expected. To do it you just list both bindings inside the "{ }". For example:
          Switch MySwitch { mqtt="blah blah bla", zwave="blah blah" }

Theoretically when one of the bindings is updated it causes a command to be sent to the other items to keep them in sync...

Hmm, I thought, could I bind one switch to TWO mqtt bindings?  [Continued below]

[papa]

Can I bind a switch to TWO mqtt bindings? Turns out I can AND shorten my config files:

      With this, I might need only ONE item with two bindings (adding second item's binding to the first item):
Switch Act_Node02 {mqtt=">[mosquitto:home/rfm_gw/sb/node02/dev16:command:ON:ON],>[mosquitto:home/rfm_gw/sb/node02/dev16:command:OFF:OFF]", mqtt="<[mosquitto:home/rfm_gw/nb/node02/dev16:state:default]"}

    NO rule would be needed for this approach.   See the FINAL correction below in the Dec 18, 2016 post.

    Same sitemap entry:
Switch item=Act_Node02 label="Node02_Output"

So the config entries are shorter, but what about the delay? Umm, it seems the same, about 5 to 17 seconds.

Regarding the "delays" from a rule, rules operate on triggers (like the change of a item's state or a cron passage of time no less than a minute).

However, eliminating the rule did not change the delay. What might cause the delay & reduce it? Any clues from 5 to 17 seconds?

       As written at the top of this post, two mqtt bindings does not fully work.  Using the item with two mqtt bindings (& no rule) does update the virtual switch on the UI (computer or app) when the node's push button toggles the node actuator (LED or Relay).  However, when the item has two mqtt bindings, the UI's virtual switch can NOT turn the node actuator on & off (BIG, unacceptable loss).  Apparently the second mqtt binding has the last & only word.

So one method that works is at the top of this thread posted on Feb 18, 2016 at 3:11pm, the one that has two separate items & a rule that postUpdates the first item based on the state of the second.  However, there is a second method (shorter) that also works.

Can I bind a switch to TWO mqtt bindings?
Turns out I can AND shorten my config files AND
(by another change) eliminate the delay mentioned above:

See the Dec 18, 2016 post below

[papa]

What might cause the delay (between pressing a node push button & the UI displaying the change) & reduce it? Any clues from the delay's being about 5 to 17 seconds?

Oh, 5-17 seconds is under 20 seconds & in Node 2's original DHT End Node sketch, TXinterval is set to 20 seconds. TXinterval can be commanded to be other values, but no less than 10 seconds. TXinterval is how long the node waits between sending data via the Gateway. So when one pushes the button on the node, the dev16 state changes, but the node waits to send the change until the latest TXinterval is completed. The delay depends on where in the latest TXinterval one pushes the node's button.

      To demonstrate this, in the DHT End Node sketch, find the line:

long TXinterval = 20; // periodic transmission interval in seconds
        Change the 20 to 10, re-save the file, & upload to the node.
Now while you can see the UI, press the node's push button. The UI's virtual switch should now change in under 10 seconds.

Caution: computourist might have defaulted TXinterval to 20 seconds & changeable to no less than 10 seconds for a performance reason. If nodes transmit too frequently, they may overwhelm the network. Perhaps it won't make much difference, if one does not have too many nodes with a short TXinterval. If needed, one might make only a device 16 change a special case that over rides TXinterval & sends immediately.

However, again the "delay" is noticeable only when one can see the User Interface while pushing the node's button.

So this thread is an exercise in noticing a felt shortcoming & a mystery & addressing them with more than one approach, including switches, rules, postUpdate, & two binding on one switch item. It was a learning experience for me & I hope for readers.

[greginkansas]

This is what I do for PIR nodes, inside the main loop. No delay

if (average >= 960) {
if (now > (lastSend + minSecsBetweenMotion * 1000l))
{
digitalWrite(LEDTXm, HIGH); // red
ackButton = true;
send8 = true;
lastSend = now;
sendMsg();
digitalWrite(LEDTXm, LOW); // red
}

[papa]

greginkansas, looks like you're implementing an immediate send for a device 8 which you've assigned to the PIR

Also looks like there should be more declarations & code related to average, now, lastSend, & minSecsBetweenMotion

I'm interested to see more.

[greginkansas]

Its a mess but here it is. I just seen, I never updated the void txRadio() to the newer one but the nodes does not crash. It also has the hoperf HP20X_DEV for pressure readings.

Attachments:

HP206C.ino (1.2 KB)

TNode_Openhab_Node_12_HP206C_ATC_V4.ino (18.48 KB)

[ragoth]

Dear Mr. Papa, My sincere thanks for starting a thread for this Delayed Response Issue. This is really a big handicap for the entire DIY Automation. I request all knowledgeable friends to pool their best brains here with their different approach to resolve this Delay issue and make this DIY Automation a bug free system. Thanks and Best Regards.

[papa]

You're welcome, ragoth. However, I want to make sure we are talking about the same thing.

In the Re-imagined RFM node code thread, your Feb 13, 2016 at 8:06am post resembles code I have provided.  However, Switch itm_node3_sw1_mqtt does not seem related to the items in the rule (Node03_Output  & Act_Node03).  Maybe you did not report what you intended ??  (Also confusing is that you use device 17 on Feb 13 & device 16 on Feb 14)

Your Feb 14, 2016 at 7:43am post in the same thread is closer to what I provided, but you are missing one item (maybe you have it, but did not report it):  Switch Node02_Output { mqtt="<[mosquitto:home/rfm_gw/nb/node02/dev16:state:default]" } READS the Node 2's device 16.  Switch Act_Node02 {mqtt=">[mosquitto:home/rfm_gw/sb/node02/dev16:command:ON:ON],>[mosquitto:home/rfm_gw/sb/node02/dev16:command:OFF:OFF]"} toggles Node 2's device 16 state as well as the virtual switch on the screen.  When a physical push button is pressed on Node 2 & changes device 16 state, Switch Node02_Output READS that & the rule uses that read to postUpdate the virtual switch represented by Switch Act_Node02.

Without the 2 items & the rule (or the alternate approach I posted above) pressing the node's physical push button will NOT show in the User Interface.  That's what my original & alternate approaches are meant to address.

On Feb 14 at 7:43am, you said "this is the code used and it takes 1 to 7 seconds as the delay is not uniform. Some times instant and some times 7 seconds or so. What I planned is a simple Switch to control a Relay(D7) to open the Front Yard Door (Node 03). it works but with a irregular delay."

Now I have some questions & comments about what you are trying to do & whether my items & Match_UI_&_Act_Node02 rule can help you or not.

This should open the Front Yard Door (just about immediately), we'll call it Node02:  D7 connected to relay input positive & Arduino GND connected to relay input negative.  Since you say it's working after a fashion, I assume you have the relay output wired ok.  << Besides this have the item Switch Act_Node02 {mqtt=">[mosquitto:home/rfm_gw/sb/node02/dev16:command:ON:ON],>[mosquitto:home/rfm_gw/sb/node02/dev16:command:OFF:OFF]"}  AND sitemap entry Switch item=Act_Node02 label="Node02_Output"

You only need the rule IF you want to push a button ON THE NODE & open the Front Yard Door AND show that on the User Interface.  & if you want that, you need the other item, Switch Node02_Output { mqtt="<[mosquitto:home/rfm_gw/nb/node02/dev16:state:default]" }  If you do NOT want or need to use a physical push button, adding the rule, especially without Switch Node02_Output { mqtt="<[mosquitto:home/rfm_gw/nb/node02/dev16:state:default]" } probably interferes with reliable operation & may be part of your problem.  If you do not use a push button on that node, I would omit the rule.

Hope this helps

[ragoth]

Yes, we are and this is a my major issue with all my Switch functions. As I tried all options like the code from your post and the code from Lewishollow and at the end, I must have posted a wrong one because all gave almost same delayed response. Not intentional, sorry if I made a blunder.

[papa]

ragoth, if you do need to ALSO use a physical button on the node to open the door ... my approaches will give some delay in that change showing on the User Interface. It's because the node software waits TXinterval seconds before it sends the data. The length of the delay depends on how much of TXinterval is left when you press the button. 

In the end node sketch, shortening TXinterval from 20 to 10, reduces how long the delay can be.  Wanting an even shorter delay would mean something like what greginkansas & I discussed above:  added sketch code so the node does not wait TXinterval, but sends device 16 changes immediately.

However, clicking the virtual switch on the User Interface should generally open the door almost immediately. Occasionally I've seen a bit of delayed response (maybe when s node has not been pinged recently ??), but not consistently.

[papa]

Thanks for posting your whole sketches, greginkansas. I'll give them a look when I get a chance. Always good to learn from others' efforts.

[ragoth]

My delay problem is with Virtual switches too, so please suggest me the best code for Virtual Switch, you published for a reliable switch function with minimum delay.
Thanks and Regards.

[papa]

As said above, This should open the Front Yard Door (just about immediately), with what we'll call Node02: D7 connected to relay input positive & Arduino GND connected to relay input negative. Since you say it's working after a fashion, I assume you have the relay output wired ok. << Besides this have the item Switch Act_Node02 {mqtt=">[mosquitto:home/rfm_gw/sb/node02/dev16:command:ON:ON],>[mosquitto:home/rfm_gw/sb/node02/dev16:command:OFF:OFF]"} AND sitemap entry Switch item=Act_Node02 label="Node02_Output"

One issue I wondered about: when I use a UI virtual switch, I'm generally clicking it to turn (via a relay) a light on or off & for them stay that way for a while. For a garage door opener, I just want to send power to a relay to in turn BRIEFLY send power to the garage door controller long enough to signal the door to move. I do NOT want that relay to stay on, but rather pulse on for a short, but adequate time then turn off.

Your node sketch might need a similar pulse to switch on your relay just long enough to open the door (with a motor?) & then go off.

      The original computourist DHT End Node reads like this
case (16): // Actuator 1
if (mes.cmd == 0) { // cmd == 0 means write
if(mes.intVal == 0 || mes.intVal == 1) {
ACT1State = mes.intVal;
digitalWrite(ACT1, ACT1State);
if (setAck) send16 = true; // acknowledge message ?
#ifdef DEBUG
Serial.print("Set LED to ");
Serial.println(ACT1State);
#endif
}}
else send16 = true; // cmd == 1 means read
break;

      This is how I adapted that node to pulse a relay so it pulsed the power to a garage door circuit board (my changes in bold):
             If you use the line delay(100);  you may need a longer or shorter delay for the relay to be on.

case (16): // BA reenabled: Actuator 1 message received
if (mes.cmd == 0) { // cmd == 0 means write
if(mes.intVal == 0 || mes.intVal == 1) {
ACT1State = mes.intVal;
// digitalWrite(ACT1, ACT1State); // original TOGGLE output
digitalWrite(ACT1, 1); // Papa: briefly turn output on then off
if (setAck) send16 = true; // original acknowledge message ?
delay(100); // Papa
digitalWrite(ACT1, 0); // Papa
if (setAck) send16 = true;
#ifdef DEBUG
Serial.println("Flashed LED/Relay");
// Serial.println(ACT1State);
#endif
}}
else send16 = true; // cmd == 1 means read
break;

[ragoth]

Thank you Papa for your time and efforts to publish all the useful details. Now I can handle this issue on my own.
Best regards.

[papa]

My apologies: The method above of using one switch item with two mqtt bindings does not work fully.

See my correction with the Feb 18, 2016 at 3:19pm post.

[computourist]

Hi papa ,

I don't know if this is still an issue. If you want instantaneous update of the node status in Openhab you need to include a "send16=true" statement, like I did in the DIG-node:



// DETECT INPUT CHANGE

//

curState = digitalRead(BTN); // Read button

msgBlock = ((millis() - lastBtnPress) < HOLDOFF); // hold-off time for additional button messages

if (!msgBlock &&  (curState != lastState)) { // input changed ?

delay(5);

lastBtnPress = millis(); // take timestamp

if (curState == LOW) {

if (toggleOnButton) { // button in toggle state ?

ACT1State = !ACT1State; // toggle output

digitalWrite(ACT1, ACT1State);

send16 = true; // send message on status change

} else

if (TIMinterval > 0 && !timerOnButton) { // button in timer state ?

timerOnButton = true; // start timer interval

ACT1State = HIGH; // switch on ACT1

digitalWrite(ACT1, ACT1State);

}}

lastState = curState;

}
It will send a message after each local update (with a max of 1 message per 10 seconds)

Also keep in mind that the current my-Openhab Android App has a bug, preventing it from updating top-level frames if there is a space in the title...

Hope this helps...

[papa]

Thanks, ct, I had previously added sendXX = true in response to other digital input changes. & I thought I had added send16 = true to the push button input section, but when I compared my coding to what you posted above, I had not done it yet.

Now I have added send16 = true when push button input changes & will see what difference it makes.

I was accepting how OpenHAB got updated without this addition: pretty quickly, but not immediately ;-) I mainly changed the thread title to UNsolved... to warn people that using two mqtt bindings did not totally work for this situation.

Thanks again for your followup.

         - Just papa, still learning like everyone else, NOT God ;-)

[papa]

For one node, I tried adding send16 = true to the BUTTON input section.

Works very nicely. A push button change on a node shows up much quicker on the user interface than waiting for it to complete the rest of its txinterval countdown. One still needs two items & one rule (using postupdate) related to the pushbutton's state, but that's ok.  For what I mean, see the first post in this thread.

Thanks, computourist, for pointing that out.

[papa]

Can I bind a switch to TWO mqtt bindings?
Turns out I can AND shorten my config files AND
(by another change) eliminate a response delay

Read this thread's first post to see what I tried to accomplish & how. Read the Feb 18, 2016 at 3:19pm post above to see how I tried to improve things, but was disappointed.

In his Jun 13, 2016 at 7:14am post, computourist solved the delay (between the node button being pushed & state change on the User Interface virtual switch).  He said to add send16 = true where I emphasize it in the code snippet below.  This works great & is included in my multi-choice node sketch since.

// DETECT INPUT CHANGE
//
curState = digitalRead(BTN); // Read button
msgBlock = ((millis() - lastBtnPress) < HOLDOFF); // hold-off time for additional button messages
// papa: ... more code in this gap
digitalWrite(ACT1, ACT1State);
send16 = true; // send message immediately on status change, don't delay for transmission interval to pass
} else

 
Next:  Bind a switch to TWO mqtt bindings successfully

[papa]

Can I bind a switch to TWO mqtt bindings?
Turns out I can AND shorten my config files AND
(by another change) eliminate a response delay

Read this thread's first post to see what I tried to accomplish & how. Read the Feb 18, 2016 at 3:19pm post above to see how I tried to improve things, but was disappointed. Read the Dec 18, 2016 post just above on fixing a delayed response.

In the Feb 18, 2016 at 3:19pm post above, I was trying to combine 2 items & 1 rule into ONE item with two mqtt bindings & get the same results: Toggle a relay or LED via the node's push button or a User Interface (UI) virtual switch & in both cases show the change in the virtual switch.  It did not fully work.

        In another thread, greginkansas wrote (I saw 2 bindings & wondered if his code worked):

        I do this [for] in and out on one item:

Switch node29_TVlight "TV stand light "{ mqtt="<[mosquitto:home/rfm_gw/nb/node29/dev16:state:default::]", mqtt=">[mosquitto:home/rfm_gw/sb/node29/dev16:command:*:default]" }

      This in the Feb 18, 2016 at 3:19pm post only partly worked:
Switch Act_Node02 { mqtt=">[mosquitto:home/rfm_gw/sb/node02/dev16:command:ON:ON],>[mosquitto:home/rfm_gw/sb/node02/dev16:command:OFF:OFF]", mqtt="<[mosquitto:home/rfm_gw/nb/node02/dev16:state:default]"}

      Based on greg's item, but his 2 bindings reversed to compare with my 2 bindings (using color coding):
Switch Act_Node02 { mqtt=">[mosquitto:home/rfm_gw/sb/node02/dev16:command:*:default]", mqtt="<[mosquitto:home/rfm_gw/nb/node02/dev16:state:default::]" }
      ^^ This version worked & didn't work like mine above:  The second binding succeeded (report state change from node button pushed), but not the first (UI switch toggling the relay or LED).

     This item based on exactly on greg's works very well:
Switch Act_Node02 { mqtt="<[mosquitto:home/rfm_gw/nb/node02/dev16:state:default::]", mqtt=">[mosquitto:home/rfm_gw/sb/node02/dev16:command:*:default]" }

     What might we see & learn from the above?  Most important in greg's version is the order of the 2 bindings: 1) (nb, northbound from the node to gateway & OpenHAB) report device 16's state & only then 2) (sb, southbound from OpenHAB/gateway) a change in the UI virtual switch commands a toggle of the device 16 state.

     To prove what I learned, I tried reversing the order of the 2 bindings in my original item from the Feb 18, 2016 at 3:19pm post:
Switch Act_Node02 { mqtt="<[mosquitto:home/rfm_gw/nb/node02/dev16:state:default]", mqtt=">[mosquitto:home/rfm_gw/sb/node02/dev16:command:ON:ON],>[mosquitto:home/rfm_gw/sb/node02/dev16:command:OFF:OFF]" }
     ^^ With this change (reversing the 2 mqtt bindings), my Feb 18 item works with the same responsiveness.

Though they differ in length & wording, greg's 2 bindings & mine function the same, but they only work in greg's order.
      Thanks greg, for much shorter code that's still fully effective.  That's what I'll use now.

PS So greg's version uses one item versus my default version of 2 items & a rule (see this thread's first post).
        The sitemap entry is the same as before:
     Switch item=Act_Node02 label="Node02_Output"

[papa]

    Another hint I got via greginkansas helped me eliminate one more item for each node.  Thanks, greg.

See this thread, the Dec 18, 2016 post that starts with "Heading back towards this thread's topic".