|
|
Post by lewishollow on Nov 30, 2015 2:02:10 GMT
I have been setting up nodes using a variety of sensors, and I have hit a wall with what should be very easy - a reed switch to tell me if a door is open or not. The use case, for context, is that I want to be able to look to see if the gate for our front yard is open before letting our dog outside. Eventually, I will hook up an LED next to the front door to indicate the gate state. The problem I'm having now is that I can't get openhab to do anything at all with the mqtt messages. The reed switch itself works fine, and the MQTT messages are working fine as well. I can subscribe via command line and see the ON and OFF messages being sent as I move the magnet close and move it away again. All of my other OpenHab items and rules are working - gas, flame, temp, humidity, light all work fine. I tried to set this up as a Contact so that I could use state == ON/OFF, but when that wasn't working, I tried to basically make my config identical to the PIR in the original instructables sketches just so I could see it doing SOMETHING. No dice.
I have the items set up like this (just the relevant parts) -
Switch itm_node3_gate_state "Front Gate Status"
Number itm_node3_gate_mqtt "Front Gate [&.1f]" {mqtt="<[mosquitto:home/rfm_gw/nb/node03/dev41:state:default]"}
// i can confirm that this mqtt string is correct since I get ON and OFF messages when subscribed to that topic in the mqtt command line
Rules -
rule "Front Yard Gate response"
when
Item itm_node3_gate_mqtt received update
then
sendCommand(itm_node3_gate_state, ON)
// note - I know that the above rule will only turn the indicator on and not back off. As I said - I was just try to see SOME response to verify that OpenHab was getting the info. Once I verify this, I'll want proper if state == ON { do thing } else {do other thing}.
sitemap -
Switch Item=itm_node3_gate_state mappings=[OFF="Off"]
Any help is appreciated. Thanks!
|
|
|
|
Post by papa on Nov 30, 2015 6:21:23 GMT
Something like this SORT OF worked for me (adapted to what I can see of your setup):
I had the digital pin for device 41 pulled DOWN (connected to ground) or OFF by a 10k resistor (when my door is open even a little). Closing the normally open reed with a magnet (when my door is closed) sets the digital pin hi or ON. image folder: icons named Gate-open.png & Gate-closed.png item file Contact FGate "Front Gate Status [%s]" <Gate> {mqtt="<[mosquitto:home/rfm_gw/nb/node03/dev41:state:OPEN:OFF],<[mosquitto:home/rfm_gw/nb/node03/dev41:state:CLOSED:ON]"} sitemap file Text item=FGate The change in reed switch shows fairly quickly on the browser user interface HOWEVER, for me, my door was usually closed & power flowing thru reed & reed failed after a couple months ( contacts "welded" closed ??). So to avoid this failure, my intent (when I get a normally closed reed switch) ... Have the digital pin for device 41 pulled UP (connected to 3.3v) or ON by a 10k resistor. Opening the normally closed reed with a magnet (when MY door is closed) sets the digital pin low or OFF. The corresponding OpenHAB config entries: image folder: icons named Gate-open.png & Gate-closed.png item file Contact FGate "Front Gate Status [%s]" <Gate> {mqtt="<[mosquitto:home/rfm_gw/nb/node03/dev41:state:OPEN:ON],<[mosquitto:home/rfm_gw/nb/node03/dev41:state:CLOSED:OFF]"} sitemap file Text item=FGate The lesson I believe I learned: Pick & use reed switches so they are open & power does NOT flow through them more than when the switch is closed & power does flow through it. PS Let me know if you also need the added sketch lines I used to handle the reed switch |
|
|
|
Post by computourist on Nov 30, 2015 7:36:34 GMT
I think this problem has to do with the way a switch is defined in Openhab. States associated with a switch in Openhab are OPEN and CLOSED.
The node reports state as ON or OFF. To remedy this you can translate switch states in the item definition:
Contact STAT2 "Status [%s]" {mqtt="<[mosquitto:home/rfm_gw/nb/node02/dev16:state:OPEN:ON],<[mosquitto:home/rfm_gw/nb/node02/dev16:state:CLOSED:OFF]"}
Normal Openhab rules can then be used. I use following rule to update the output state of one of my nodes:
rule "Update OUT2" // update state OUT2 after local node switch toggle
when
Item STAT2 received update
then
if (STAT2.state==OPEN) {
postUpdate(OUT2, ON)}
if (STAT2.state==CLOSED) {
postUpdate(OUT2, OFF)}
// logInfo("stat2 changed: ", STAT2.state.toString())
end
|
|
|
|
Post by lewishollow on Nov 30, 2015 18:04:35 GMT
Thanks guys! I'll give this code a go tonight. My reed switch is indeed closed when the gate is closed, which could lead to the fusing you're talking about. I'll try it out as is, but I may change out the switch if it doesn't work out. The openhab part was the part that was really killing me - I couldn't get the most basic of rules to work when using the reed switch. I was even having trouble finding good docs for openhab to figure it out for myself, which is even more frustrating - there is a lot of info out there, but I couldn't find a single comprehensive set of docs listing all of the syntax and APIs.
Anyway - I'm really close to having a cool story to post for my use case. Thanks for the help!
|
|
|
|
Post by papa on Nov 30, 2015 19:57:23 GMT
Yes, as Computourist suggests, I've used postUpdate rules to make sure my sitemap SWITCHES match what's on the node, like from a node pushbutton press. For me, without postUpdate rules, the Contact items have updated fairly quickly on the browser user interface.
PS I look forward to hearing the story of your implementation & documentation of how you did it.
We can often learn something from each others' approaches.
|
|
|
|
Post by lewishollow on Nov 30, 2015 21:26:01 GMT
Thank you both for the help. I'm looking forward to sharing the details of my setup once everything is in a functional state!
|
|
|
|
Post by lewishollow on Dec 1, 2015 7:18:06 GMT
This is just mind-boggling.
So after a lot of tweaking and editing config files, I was finally able to see updates in the OpenHAB log indicating that the state was changing between OFF and ON for my gate item. This only worked when I used this line in items -
String itm_node3_gate_mqtt "Front Gate [%s]" {mqtt="<[mosquitto:home/rfm_gw/nb/node03/dev41:state:default]"}
Using the contact type you both recommended yielded no response in the log.
This is at least progress, though I would like to use the proper contact type. Regardless, the bugger of it is that I STILL cannot get the OpenHAB UI to reflect that state. I tried just putting a text item directly in site map to try to just directly display the state of itm_node3_gate_mqtt-
Text item=itm_node3_gate_mqtt
And I also tried using a rule to post updates to switches and text fields that I created as I went along. For example -
Items -
Switch gateStatus
String itm_node3_gate_mqtt "Front Gate [%s]" {mqtt="<[mosquitto:home/rfm_gw/nb/node03/dev41:state:default]"}
rules -
when
Item itm_node3_gate_mqtt receieved update
then
if (itm_node3_gate_mqtt.state == ON)
{
sendCommand(gateStatus, ON)
}
if (itm_node3_gate_mqtt.state == OFF)
{
sendCommand(gateStatus, OFF)
}
sitemap -
Switch gateStatus
No response in the OpenHAB UI whatsoever. All of my other text fields and switches are working just fine. It just makes no sense...
Thanks again for all of your help! As frustrating as this particular issue is, I'm still having a blast working through these issues.
|
|
|
|
Post by lewishollow on Dec 1, 2015 8:06:59 GMT
Also note - since I have the item defined as I string, I tried if (itm_node3_gate_mqtt.state == "OFF") and if (itm_node3_gate_mqtt.state == "ON"). Still no go. Though I'm not sure that's even a valid way to compare strings in openhab's scripting language (which is probably something like Java? if so - then that should be a valid way to compare strings).
|
|
|
|
Post by papa on Dec 2, 2015 22:53:16 GMT
Sorry it's giving you fits. As happened today, I sometimes find I've missed some important detail because I'm staring at & fiddling with other details in a mass of code or hardware.
Sometimes the simplest things cause problems, like for me yesterday when I used Node88 (uppercase "n") instead of node88
in a {mqtt="<[mosquitto:home/rfm_gw/... item.
A Contact item should work. If you're still trying to fix this ...
... Please answer these questions so maybe I (& maybe you) can see what's happening
How did you wire the reed switch to the node? (digital pin, resistor, etc.)
What relevant code do you use in the node sketch? (variables like pin used, device assigned, testing for input from the reed, how it's sent to the gateway) You might just post the latest version of your sketch.
According to whether you have a pull UP or pull down resistor with the reed switch & digital pin, please copy one version of the OpenHAB config material that I posted above on Nov 30 & paste it into your respective config files. As much as possible leave it as is without editing. If you do edit it, please post all of your versions of that config material. What results do you get? If you can connect the node to a computer in debug mode, what do you see?
|
|
|
|
Post by lewishollow on Dec 5, 2015 21:20:01 GMT
I'll post the code if necessary (it's a work-in-progress at the moment), but I don't think the code is the issue, nor is a mismatch of device IDs or pins, etc. As proof - I see the message coming out of the node saying it's sending off/on, and the MQTT server is getting the message -
pi@raspberrypi ~ $ mosquitto_sub -t home/rfm_gw/nb/node03/dev41
ON
OFF
The way my current reed switch works is when the magnets are close, ON is sent. When apart, OFF is sent. Also, as mentioned, switching the item type to a string does get the ON/OFF value, though it was still refusing to DO anything with that value.
Basically - it seems that the node and MQTT are doing the right thing. it seems like something not working in OpenHAB.
|
|
|
|
Post by lewishollow on Dec 5, 2015 21:24:58 GMT
PS - I copied your code EXACTLY, papa, and even removed everything else so that it was just these lines in the config files. Still nothing.
|
|
|
|
Post by lewishollow on Dec 5, 2015 21:59:51 GMT
For the sake of simplicity and the elimination of variables - I switched to the old node code and tried again. I just repurposed the BTN in the original DHT node to read the reed switch state. All I changed was the device ID from 40 to 41 wherever applicable, set my encryption key, and changed node 2 to node 3. This was using node code 2.1. No difference.
|
|
|
|
Post by papa on Dec 6, 2015 21:53:26 GMT
These things can be maddening, but eventually you'll probably learn as much or more from this problem as your successes. Believe me, I've had similar problem experiences, including recently.
Again usually what happens is I've been starting at & fiddling with some details & I missed some other important detail.
Hang in there, but for now, I suggest you work on other things for a day or so & come back to this problem & then rechecking everything hardware & software. Sounds like a good approach to limit as much as possible to reed switch related stuff.
Sounds like from your first post on this issue, that the node is SENDING the data, but for some reason, the data is not showing on the OpenHAB user interface. You also say your other sensor data shows fine on the user interface. That leads me to believe that something is wrong with the OpenHAB config files related to the reed switch, maybe something subtle & hard to see.
When you edit the OpenHAB config files, are you using OpenHAB Designer or (open source) Notepad++? Because Windows WordPad & Notepad & the like treat line endings differently than what Raspberry Pi / Linux needs. Could that be the problem? I've seen that happen for others.
|
|
|
|
Post by papa on Dec 7, 2015 0:22:33 GMT
Another thought about your reed switch issues...
The folder \openhab\logs contains files named like events-2015-xx.log.zip a zip file of events-2015-xx.log that list OpenHAB successes & errors. Scroll through recent log files looking for errors naming things related to how you've referred to the reed switch in the OpenHAB config files. |
|
|
|
Post by lewishollow on Dec 8, 2015 16:24:35 GMT
Moving to the designer did the trick! I was developing everything on my pi using text editors. I moved all of my config files to my windows machine and worked on them in the openhab designer, and now everything is functional! I really should have done so sooner. It would have saved me a lot of pain. Ah well. Lesson learned. Thanks for the help! And again - I still fully plan to post all of the details of my setup soon.
|
|
|
|
Post by papa on Dec 8, 2015 18:42:28 GMT
Glad one of the suggestions helped & that it's working now.
Again, I look forward to seeing documentation on what you've done, especially on things not yet documented on this forum.
|
|
|
|
Post by papa on Dec 11, 2015 2:53:24 GMT
On Nov. 30, 12:21am I reported
Yesterday my reed switches arrived. Turns out I had not read the listing closely enough & I got more normally open reed switches though these are protected in plastic & have short hook up wires. Ordered more switches that can be EITHER normal open or normally closed, cost more, but more flexible to needs. Meanwhile I installed a new reed switch to see how it will last. Maybe I had damaged the previous unprotected reed switch (just a fragile glass tube) so it worked for a while then failed. We'll see. Meanwhile the node is successfully reporting when the door is open & closed.
|
|
|
|
Post by lewishollow on Dec 13, 2015 18:14:19 GMT
I still haven't deployed my node that uses the reed switch, but I believe today will be the day. I will report on my results with the roll-up of my implementation.
To close the loop on the problems I was having with the reed switch in OpenHAB - it turned out that it WASN'T just a missed error or new line character issue. When the problem seemed fixed it was after setting up the designer on my windows machine and moving all of the config files from my pi. I set up an MQTT broker and the OpenHAB runtime on my Windows PC to be able to have a totally isolated test environment. Then, once all was functional, I wrote some scripts to be able to publish my changes to the pi. After all of that, the contact STILL wasn't working on my pi. I discovered that I had configured OpenHAB on my pi using a set of instructions I found that specifically used 1.5.1 for the instructions, which I followed verbatim. I realized there was a later version, updated my OpenHAB, and now all is well!
|
|
|
|
Post by papa on Dec 13, 2015 18:39:14 GMT
Excellent news that things are working.
Good troubleshooting. That's what it takes. A good reminder for us to check for updates when problems arise.
If you could, please document what you learned, including pitfalls to watch for pi set up.
I imagine that could be helpful to others. In fact, I hope to migrate from Windows to pi someday.
|
|
|
|
Post by chrisinkc on Feb 21, 2016 22:32:54 GMT
Papa, I have a question about your setup. I setup my garage doors using your code. Here is my code:
SITEMAP
Switch item=Act_Node03 label="Garage Door 1 Opener" mappings=[ON="GD1"]
Text item=garagedoor1
Switch item=Act_Node04 label="Garage Door 2 Opener" mappings=[ON="GD2"]
Text item=garagedoor2
ITEMS
// reed switch for garage door 1
Contact garagedoor1 "Garage Door 1 Status [%s]" <garagedoor> {mqtt="<[mosquitto:home/rfm_gw/nb/node02/dev42:state:OPEN:ON],<[mosquitto:home/rfm_gw/nb/node02/dev42:state:CLOSED:OFF]"}
// reed switch for garage door 2
Contact garagedoor2 "Garage Door 2 Status [%s]" <garagedoor> {mqtt="<[mosquitto:home/rfm_gw/nb/node02/dev41:state:OPEN:ON],<[mosquitto:home/rfm_gw/nb/node02/dev41:state:CLOSED:OFF]"}
Everything is connect correctly, and works correctly, but I have to refresh the browser or my iphone app to see the garage status change. It won't just update on its own. Isn't it suppose to change the garage door icon to the closed garage door icon without me having to refresh the browser?
|
|
|
|
Post by greginkansas on Feb 22, 2016 1:27:48 GMT
Two things I see. The browser, some work some some don't. If you change rules or items files force reload the site. The app needs reloaded also.
|
|
|
|
Post by papa on Feb 22, 2016 1:35:02 GMT
When I use the UI on a regular computer (on the same network with the Gateway) & click the virtual push button switch to open or close a garage door, the status read from the reed switch usually changes almost immediately. My TXinterval for the garage door opener node is 20 seconds. I use the Firefox browser on Windows & Linux.
When I use the iPhone app, sometimes I believe it changes after a little delay, but maybe half the time, I have to close the app & restart it to see the changed status read from the reed switch.
I don't know why. I guess I wondered if it was something to do with going thru my.openhab.org.
As greginkansas said, sometimes it takes a little while before OpenHAB reloads changed config files. However, I have the above behavior even when I have NOT made recent config changes.
If you figure out something, please share. I'm at a very long distance from where that node is working & cannot be close to test it for a good while.
|
|
|
|
Post by papa on Feb 22, 2016 21:39:56 GMT
chrisinkc, regarding getting a notification that the garage door has opened or closed, here's something I just looked into here: Looks like this requires using my.openhab.org |
|
