|
Post by papa on Dec 4, 2018 22:39:12 GMT
ngy, for your reported issue, these OpenHAB config entries are relevant: the item: Switch Act_Node02 "Garage Door" <garage3> ["Switchable"] { mqtt="<[mosquitto:home/rfm_gw/nb/node02/dev16:state:default::]", mqtt=">[mosquitto:home/rfm_gw/sb/node02/dev16:command:*:default]" }
& sitemap entry: Switch item=Act_Node02 label="Garage Door" mappings=[ON="OPEN/CLOSE"] Before you answered me: "no other items or rules. only have the garage door opener node, and the door sensor node." Is that still true, that you do not have any rules that command Node02?The above item & sitemap entry basically look OK, except I wonder about one thing:
Does ["Switchable"] in the item mean you are using something like Alexa for voice control? If so, could it be that somehow when OpenHAB reboots, the voice control sends an ON command to Node?
Have you tried removing ["Switchable"] from the item & then rebooting OpenHAB?
|
|
ngy
Junior Member
Posts: 58
|
Post by ngy on Dec 5, 2018 16:38:05 GMT
Hi papa,
Correct, the ["Switchable"] is so my google assistant knows that the item is a switch. And yes, still true, I have no additional rules that command Node02.
I will try removing the switchable option and see if that affects the garage door.
Thanks,
|
|
|
Post by papa on Dec 5, 2018 20:04:00 GMT
ngy: "I will try removing the switchable option [from Act_Node02] and see if that affects the garage door.
papa: Yes, please do. Other than that option, I believe your gateway & garage door opener node & OpenHAB configs are like mine. I have tested stopping & starting the OpenHAB2 service AND rebooting my computer running the OpenHAB2 service. When I restart OpenHAB in these 2 ways, my garage door does not open. During these restarts & the Gateway is connected to USB, the Serial Monitor reports that the Garage Opener Node's device 16 remains as off. Thus, I am not able to reproduce your issue & do not have the ability to test with google assistant.
If the google assistant connection is causing the issue, perhaps a change of settings or an added rule can avoid the issue.
|
|
ngy
Junior Member
Posts: 58
|
Post by ngy on Dec 6, 2018 16:44:32 GMT
So I removed the ["Switchable"], but unfortunately, the garage door still triggers. So that is not the issue.
I used myopenhab cloud connector to monitor and send me notifications, and I can see that it is indeed triggering independently of 'Act_Node02'. See the event log here:
Today at 11:11 AM gCarDr03 CLOSED
Today at 11:10 AM Act_Node02 OFF
Today at 11:10 AM Act_Node02 ON
Today at 11:10 AM gCarDr03 OPEN
Today at 11:04 AM gCarDr03 CLOSED
Today at 11:04 AM Act_Node02 OFF
Today at 11:04 AM Act_Node02 ON
Today at 11:01 AM gCarDr03 OPEN
Today at 11:01 AM Act_Node02 OFF
Today at 11:01 AM Act_Node02 ON
At 11:10 AM, the gCarDr03 opened on its own (I rebooted the pi), without Act_Node02 being triggered...
|
|
ngy
Junior Member
Posts: 58
|
Post by ngy on Dec 6, 2018 16:45:20 GMT
next will be for me to plug the gateway in and monitor the output when I restart it...
|
|
|
Post by papa on Dec 6, 2018 20:43:47 GMT
Boy, this issue is literally "the gift that keeps giving," isn't it? ;-) Please check & report which Gateway sketch version AND which Node Choices sketch version programmed your devices. The versions should be reported, when you start the serial monitor with each device connected to USB. ============================================
PS, I'm not sure the following will help, but it's worth a try:
In OpenHAB2's \conf\rules folder, create a new Garage.rules file
In Garage.rules, create this rule:
rule "Initialize_Garage_Door_Opener" when System started then Act_Node02.postUpdate(OFF) // ?? Make sure garage door opener starts with OFF ?? end
|
|
ngy
Junior Member
Posts: 58
|
Post by ngy on Dec 7, 2018 15:58:52 GMT
Boy, this issue is literally "the gift that keeps giving," isn't it? ;-) Please check & report which Gateway sketch version AND which Node Choices sketch version programmed your devices. The versions should be reported, when you start the serial monitor with each device connected to USB. ============================================
PS, I'm not sure the following will help, but it's worth a try:
In OpenHAB2's \conf\rules folder, create a new Garage.rules file
In Garage.rules, create this rule:
rule "Initialize_Garage_Door_Opener" when System started then Act_Node02.postUpdate(OFF) // ?? Make sure garage door opener starts with OFF ?? end
i'll give that rule a try, but based on the timing of when the garage door is triggered, it happens pretty fast, before anything is initiated (it feels like). I'll find some time to plug the gateway in first to the serial monitor and get back to you about the version. The node choices sketch version is 2.2 MhC
|
|
|
Post by papa on Dec 7, 2018 16:55:43 GMT
ngy: "The node choices sketch version is 2.2 MhC" papa: Version MhC is a ways back. I encourage you to use the latest version & customization posted here. I'm starting to get a vague memory that I might have had a similar issue to yours. Perhaps I made a fix since MhC that will help. MhC was early in the code for the AutoRadio feature. It may have had some kinks that I worked out later.
Besides the Gateway version, for whichever the last node sketch you use, please also provide your node customization, the #define lines you UNcommented. Except do not share your ENCRYPTION KEY.
ngy: "i'll give that rule a try, but based on the timing of when the garage door is triggered, it happens pretty fast, before anything is initiated (it feels like)." papa: yes, I had the same concern so I did not offer much hope about the rule, but again maybe worth a quick try.
|
|
ngy
Junior Member
Posts: 58
|
Post by ngy on Dec 7, 2018 20:49:12 GMT
ngy: "The node choices sketch version is 2.2 MhC" papa: Version MhC is a ways back. I encourage you to use the latest version & customization posted here. I'm starting to get a vague memory that I might have had a similar issue to yours. Perhaps I made a fix since MhC that will help. MhC was early in the code for the AutoRadio feature. It may have had some kinks that I worked out later.
Besides the Gateway version, for whichever the last node sketch you use, please also provide your node customization, the #define lines you UNcommented. Except do not share your ENCRYPTION KEY.
ngy: "i'll give that rule a try, but based on the timing of when the garage door is triggered, it happens pretty fast, before anything is initiated (it feels like)." papa: yes, I had the same concern so I did not offer much hope about the rule, but again maybe worth a quick try. i see, i'll update to the latest node sketch MhF9q and report my findings. My gateway is 25.1_pub1. I notice there's a 25.1_pub5 as well. I'll update to that tonight, and see if that resolves the issues. I'll try the rule method if all else fails.
|
|
|
Post by papa on Dec 8, 2018 2:33:21 GMT
ngy: "My gateway is 25.1_pub1. I notice there's a 25.1_pub5 as well. I'll update to that tonight" papa: OK, in the Gateway thread, find the latest gateway sketch in this post. Then in the next posts, follow the NEW customization for that sketch. For sure, move your current ENCRYPTKEY into the new #ifdef NetworkOne section & populate the rest of that section. ngy: "i'll update to the latest node sketch MhF9q and report my findings." papa: In this post, I provided the latest node choices sketch, which fixes a DHT glitch I introduced earlier.
Follow the initial customization in that post & add UNcommenting #define GOPENER
|
|
|
Post by papa on Dec 9, 2018 22:24:21 GMT
ngy, Experimenting more with the Gateways, I finally was able to duplicate your issue. Using a GW 2.5.1 Gateway & connecting it to USB & Ethernet, I got this on the IDE Serial Monitor (SM) as the Gateway restarted: (node98 is my garage door opener node)
The above is a Gateway / Network 2. Because my garage door opener node is on Gateway / Network 1, SM only showed the MQTT-Topic...device 16 message, but my garage door did NOT open. Then I programmed a Gateway / Network 1, which IS the network of my garage door opener node & got these SM results: Serial Monitor not only showed the device 16 Topic message, BUT ALSO opened my garage door, even though node98/device16 has an OFF state. This does NOT happen with a much earlier Gateway version. So I believe the problem is something about the programmed connection between Gateway 2.5.1 & the Garage Door Opener node. I'll look over both sketches. Trouble is I'm not so confident in understanding much of the Gateway code, but will see what I find.
For one clue, that MQTT-Topic message is sb (southbound) from Gateway to Node, & it happens early in when the Gateway connects to Ethernet/MQTT. That message may point to what is triggering the opening of our garage doors. Stay tuned.
|
|
|
Post by papa on Dec 10, 2018 4:45:46 GMT
More to the story: The issue (garage door opener flashed when OpenHAB or Gateway boots up) CAN happen even with an earlier Gateway version. The earlier Gateway version gives more feedback on the Serial Monitor:
So an ON Topic comes by way of Mosquitto (& OpenHAB ??) & is sent to the garage opener node (98)
The Topic received looks like the command portion of the Act_Node98 Item.
On the Serial Monitor, the garage opener node shows this when OpenHAB or Gateway are restarting:
Weirdly, this happens even when I disable the Act_Node98 Item. I don't know how this phantom ON command is happening.
|
|
|
Post by papa on Dec 10, 2018 7:36:18 GMT
I'm still not sure how the phantom ON command is being sent to the garage opener node. I suspect Mosquitto holds it & then dumps it when communication resumes. I do know WHEN the command is sent & I believe I have a work around.WHEN: The issue happens after the Gateway looses connection with the Mosquitto MQTT service AND then regains connection. Connection is lost when the Mosquitto service is stopped on the host computer (like rebooting the Pi) OR when the Gateway looses Ethernet connection to the local network (losing power to Gateway or router, disconnecting the network cable from the Gateway). When a Mosquitto / Gateway connection is regained, a Garage Opener ON command is sent from somewhere.Every 60 seconds, the node tries to send its data to the Gateway. If the send fails 7 times, the node's DEBUG reports "No connection..." My workaround code has the garage opener node skip the first command it receives after Mosquitto & Gateway are connected. This ignores the (leftover ??) UNwanted ON command just after the node boots up & later after the node's DEBUG reports "No connection..." Just after the node reboots, it also ignores the first click of the garage opener virtual button on the User Interface, but that seems a small price.
I hope to post the updated sketch later today.
|
|
|
Post by papa on Dec 10, 2018 15:57:03 GMT
Now I also know the source of the unwanted ON command sent to the garage opener node just after the Mosquitto / Gateway connection is regained. My suspicion was right that Mosquitto holds it & then dumps it when communication resumes. Before sleep, I searched Mosquitto folders & found nothing suspicious. After some sleep & mulling, I searched the mqtt.cfg file. There, I found these lines (ngy, see here, looks like I copied how brump recommended that you change the default & I copied it.): Then I found this community.openhab thread where knowledgeable Rikoshak confirmed: "When you send a message with the retain bit, that message will stay on that topic until another message with a retain bit gets published to that topic. This means any time the device loses its connection from the broker will get the retained message when it reconnects whether or not it has already processed that message. That may be perfectly acceptable in your case or it may be a disaster, [including] momentary actuators like my garage door openers where I absolutely do not want to use the retain bit." In the thread, Rikoshak cautions about how we might use mosquitto.retain & hints how we might specify whether an item uses retain or not. (define one mosquitto broker name with retain=false & another with retain=true). Now I wonder about just restoring the mqtt.retain=false setting in mqtt.cfg. Will I really lose anything important? Will I avoid mysteries like ngy & I have been chasing? Oh boy, more testing to do ;-)
|
|
ngy
Junior Member
Posts: 58
|
Post by ngy on Dec 10, 2018 16:30:47 GMT
wow!!! I'm glad you discovered more with regards to the phantom on issue! I updated my node to MhF9q and still have the issue (unsurprisingly now that you've discovered the issue with the gateway).
so (pardon my ignorance), wouldn't simply changing mosquitto.retain to false, solve this issue?
|
|
|
Post by papa on Dec 10, 2018 16:34:39 GMT
ngy: "wouldn't simply changing mosquitto.retain to false, solve this issue?'
papa: Yes, ngy, I believe so. I tested restoring the default of mosquitto.retain=false. Again, weirdly, when I broke the Mosquitto / Gateway connection, the garage door opener node was flashed sometimes & sometimes not. After breaking the connection several times, then the garage door opener node is consistently NOT flashed. The above makes me wonder if Mosquitto has a cache of more than one retained messages that needed to be flushed out. So, ngy, try this: In OpenHAB 2's \conf\services folder, open mqtt.cfg. Comment out (put # at the start) the line mqtt.retain=true Be aware you may need to break the Mosquitto / Gateway connection several times before it is consistently reliable. To break connection, you can unplug network cable from Gateway OR stop & restart the Mosquitto service on the Pi. You don't need to reboot the PI until maybe a final test.
Let's pay attention to see if changing mqtt.retain causes other issues. But there's probably a good reason that the default is false.
|
|
ngy
Junior Member
Posts: 58
|
Post by ngy on Dec 10, 2018 16:47:52 GMT
one question to ask is why did we enable them to be true in the first place? what was the purpose for it?
i'll comment it out and report my findings. and thanks again for the great support in diagnosing and reproducing my issue!
|
|
|
Post by papa on Dec 10, 2018 21:16:53 GMT
ngy: one question to ask is why did we enable them to be true in the first place?
Configure mqtt binding on OH2: Find the file and open: mqtt.cfg mosquitto.url=tcp://localhost:1883 mosquitto.clientId=openhab mosquitto.retain=truemosquitto.async=false papa: See this post where brump recommended that you (ngy) use the mosquitto.retain=true setting. I must have copied that & then (in mqtt.cfg) left the bread crumb of # brump, ngy to help me know or find how I changed that setting. (PS in that post, I left a caution about mosquitto.retain.) ngy: what was the purpose for changing [mosquitto.retain]? papa: Maybe brump will say his reason. I guess I thought "seems like a good idea, could not hurt, maybe help." Another lesson that assuming can come back to bite us.
ngy: i'll comment out the mosquitto.retain setting and report my findings. papa: Yes, please report your results. & remember you may need to break the Mosquitto/Gateway several times to flush retained messages.
ngy: and thanks again for the great support in diagnosing and reproducing my issue!
papa: You are welcome. We had quite a trip into the bowels of this DIY Home Automation stuff.
Remember to give back ideas, projects, & hints to the forum when you see areas where you can contribute, maybe including engineering insights & suggestions.
|
|
ngy
Junior Member
Posts: 58
|
Post by ngy on Dec 11, 2018 17:12:19 GMT
Hi papa,
How many times do I have to unplug/replug the gateway? I did it for about 30 minutes last night, and including rebooting my pi twice (once last night, once this morning) and it still triggers the garage door. When I unplug my gateway, I wait for the MQTT light to turn off, before plugging it in and let it receive a few messages before unplugging it again.
Thanks,
|
|
|
Post by papa on Dec 11, 2018 20:46:55 GMT
I needed to break the Mosquitto / Gateway connection several times before the problem cleared up totally. I found the fastest way was to stop & restart the Mosquitto service on the computer.
If that does not work for you, just say so & I'll post the sketch with the work around code that I created.
|
|
ngy
Junior Member
Posts: 58
|
Post by ngy on Dec 12, 2018 20:24:12 GMT
Hmmm, I tried it a few more types with restarting the mosquitto service, it is indeed faster, but I am still getting a trigger to the garage door unfortunately.
I tried flashing to the latest gateway sketch too (2.5.1 pub5) but still activating... will try rebooting the service a few more times tonight.
might take you up on the work around code.
|
|
|
Post by papa on Dec 13, 2018 12:52:34 GMT
I now believe mosquito.retain is the problem & seems to store several commands (maybe depending on how many times we used the open command before) that then get released each time mqtt Svc gets restored.
|
|
|
Post by papa on Jan 1, 2019 22:51:25 GMT
Addressing Security Concerns of the Garage Door Opener Node
Turns out setting mosquitto.retain to false (in \conf\services\mqtt.cfg) & flushing out previously stored Garage Opener flashes did NOT always solve the problem. Seem like later Garage Opener flashes sent via the User Interface were still somehow retained. Because when the Node / Mosquitto / MQTT communication was broken & then re-established, the Garage Door Opener was sometimes flashed, opening the garage door when we would not want that. NOT good. The latest choose node sketch now has my work around code for the Garage Opener node. The work around ignores the first packet after MQTT communication is re-established. So it will also ignore at least one user interface command after MQTT communication is established. This should be more secure.
|
|
|
Post by papa on Jan 2, 2019 16:05:38 GMT
Addressing Security Concerns of the Garage Door Opener Node
Thoughts: We have established that when the Gateway loses then regains communication with OpenHAB / Mosquitto / MQTT, the Gateway sends a command to flash the garage door opener node's relay. In \conf\services\mqtt.cfg, I commented out mosquitto.retain & that seemed to help. However, rebooting the Gateway still flashed the relay sometimes. To be safe, I have now changed the setting to mosquitto.retain=false, but that should be no different from commenting it out since the setting defaults to false.
I believe the work around mentioned in the last post is helpful. After a couple phantom relay flashes (flushing left over commands ?), rebooting the Gateway has not sent phantom relay flashes.
One idea on a source of the phantom relay flashes: After the Gateway regains connection with OpenHAB / Mosquitto / MQTT, it still takes a while for the node to regain connection via the Gateway. In that time gap (in my impatience), I clicked the user interface switch for the node several time. If we have the UI send commands & they cannot get through, perhaps they are stored & sent the next time the Gateway reboots. If I have time & opportunity, I will test this theory.
In the next few days, I'll try to do some more testing. After that, I may not be able to test it for a few months. For now, be advised to watch this node carefully or even disconnect it. Also for now, I recommend that we wait for the garage door opener node to have connection with OpenHAB / Mosquitto / MQTT, before we try to send it a command.
|
|
|
Post by papa on Jan 4, 2019 16:22:41 GMT
I'm More Reassured about the Garage Door Opener Node
The Garage Door Opener node is programmed with the work around code mentioned above. In \conf\services\mqtt.cfg, I have the setting mosquitto.retain=false. For testing I have rebooted my gateway & also rebooted mosquitto service. In between, I clicked the user interface button for the node. Fortunately I have not been able to generate the problem of flashing the Garage Door Opener relay when MQTT communication is broken & then re-established. Other than one or two incidents after I took the above actions, I have not had a problem with the node. Again for now, be advised to watch this node carefully. Also for now, I recommend that we wait for the garage door opener node to have connection with OpenHAB / Mosquitto / MQTT, before we try to send it a command.
|
|
ngy
Junior Member
Posts: 58
|
Post by ngy on Jan 16, 2019 18:40:44 GMT
Hi papa! Merry Christmas and happy new year.
Sorry I just got back from the Christmas break and finally got a chance to come take a look again.
With the old sketch, I am STILL getting the garage door flash when I reboot the router or MQTT gateway.
I'll try out your latest sketch, and let you know how it goes. Thanks again!
|
|