I’ll be honest, i don’t care how the light is turned on. If it means having two items and a rule stating when item1 changes (when the light switch is pressed) then toggle item2 or if it means having them both on the one item, i really don’t mind. I have no use for the item i’ve assigned to the light switch other than to toggle the other item.
So it would make sense to have a single item represent the ceiling lights, taking both commands to turn it on and off, and showing the state of the lights. I suggest studying and trying my item definition, and eliminating unnecessary rules for coordinating one item with another item.
Would your method require any rules to work at all or is it just waiting for a command/state on both MQTT topics and then to perform accordingly?
The single item is subscribing to one topic in order to maintain the correct state of the item, and then publishing to the other topic in order to turn the switch on or off. It’s using autoupdate="false" to keep your moving the switch from updating the state of the item, instead only updating when the MQTT topic says to. If that’s all you want, then I don’t see any reason for rules.
Hmm interesting. I never knew we could have one item listening and serving to two different topics… Thank you for giving me this knowledge. I will trial this later on tonight when i get home from work.
What do did you mean when you said “to keep your moving”, i can’t workout what its supposed to mean or if there was a typing error, sorry.
By default, when you send a command to an item (like from the UI), the state of the item is changed to match. But you don’t want that in this case; you only want the state to change when you publish the real ceiling light state to MQTT. So by adding , autoupdate="false", you suppress the automatic updating of the item’s state.
I understand the reason for the false update, but i dont understand your wording of “To keep your moving”.
I can’t quote correctly using a mobile here for some reason. Sorry for the previous post not making much sense compared to this.
It means “to prevent the normal effect of you moving the switch in the UI (from on to off or vice versa) from changing the state of the item.”
Right okay, thank you for explaining. I will give this a try later. So keep the sitemap the same, displaying the switch, rules removed and modify the items to what you propose? Anything else i should do to make this work?
Just the one item, shown in the sitemap, ought to work, but please study the item and understand the reasons behind how it’s defined, and you should be fine!
I have commented out my rules, then made the items file to read:
Switch CinemaRoom_Light01 "Ceiling Lights" <light> (SF_CinemaRoom, gSWitch, gLight) {mqtt="<[mymosquitto:Gateway1-out/3/3/1/0/2:MAP(1on2off.map)], >[mymosquitto:Gateway1-in/4/1/1/0/2:command:ON:1], >[mymosquitto:Gateway1-in/4/1/1/0/2:command:OFF:0]", autoupdate="false"}
with no hope. Time to start the troubleshooting. Can you see any silly mistakes here?
I don’t see any errors with the one-line item file, but you are aware that if you haven’t defined the Group items SF_CinemaRoom, gSWitch, and gLight in some .items file, you should. I also don’t know what is contained in your transform/1on2off.map file, and if it matches what messages are published for ON and OFF by your MySensors. I also don’t know if the MQTT topics are specified correctly, but I assume you would understand that.
Try using mosquitto_sub on the topic(s) that are being published, so you can follow along independent of openHAB.
I do indeed have all that correctly created and in place, I’m also monitoring the topics to allow me to see if its got to that point too.
I have removed the following from the item and it works. However this means that the switch itself isn’t communicating to turn the light off. If this works as you intend it to, i am able to manually toggle the light through the OpenHAB ui on my browser, or do you think that i just wanted it to be controlled by only the switch?
<[mymosquitto:Gateway1-out/3/3/1/0/2:MAP(1on2off.map)]
The “subscribe” clause that you removed was wrong. Add it back with this version:
<[mymosquitto:Gateway1-out/3/3/1/0/2:state:MAP(1on2off.map)]
The section :state was missing, which means update the state when your device publishes to the given topic. See the MQTT binding wiki.
Is your topic Gateway1-out/3/3/1/0/2 updated when the ceiling lights turn off and on? If so, adding the clause back in to the binding config string will update the state when it the value you map is published to the topic.
Because i’m still on a beginner level of understanding the bindings and the syntax of OpenHab, i didn’t realize that, i copied and pasted what you advised me to add, but because i know not much about this section i didn’t recognize the error, sorry.
With that corrected and implimented back into the item the topic “Gateway1-in/4/1/1/0/2” is showing a change of 1s and 0s when i switch the switch on the openhab web UI, perfect. Nothing on the “Gateway1-out/3/3/1/0/2” when i toggle this same switch. However, the topic “Gateway1-out/3/3/1/0/2” does show activity of 1s and 0s when i switch the physical light switch.
So from this we can assume that the physical switch is connected and talking to OpenHab correctly. We can also assume that the web ui switch is connected to the correct topic for the MySensors to turn the relay on and off correctly.
It is same to assume that my issue now is lying on the items bindings still, right?
Please excuse me if i’m being dumb here but, how does OpenHab send an update to the MQTT topic for the switch to know if the light has changed if there is no outgoing on the switch topic in the item binding?
I think i may have found the issue, but i’m unsure how to resolve it. I had a strange feeling that it wasn’t getting a reading from the topic of the light switch, so i made sure it was present by subscribing to it, sure enough it was there and receiving updates from the light switch, however it wasn’t showing in the sitemap. I made another item to troubleshoot this, so i made a simple basic number item, and mapped it to the same mapping file (1on2off.map). This contains the following:
0=Off
1=On
-=Unavailable
The new item was:
Number CinemaRoom_Switch01 "Light Switch [MAP(1on2off.map):%s]" <shield> (SF_CinemaRoom, gSwitch) {mqtt="<[mymosquitto:Gateway1-out/3/3/1/0/2:state:default]"}
I switched back to the web UI and refreshed, and there was the item showing “unavailable” as its value. I can confirm that there is a “1” sitting on the topic that the item is linked to.
Am i making a fundamental error here or am i correct in thinking i should see that item display On (Because 1 translated in the mapping file is On)?
Your map file should map 0 to OFF (not Off) and 1 to ON (not On). The binding will understand that the MQTT message 0, mapped to OFF, will set the Switch item to OFF. Likewise for 1, mapped to ON, will set the Switch item to ON.
I have a habit of thinking like, “Even if its wrong, i would expect to see something” when actually i should just correct it there and then.
I know that on and off commands should be capitalized but i chose not to correct it thinking it wouldn’t be the issue as i can’t see anything at all on the topic. So i was sitting here saying “Even if its wrong, i should expect to see it on the topic, even if its interpreted correctly or not, it will be on the topic” to myself.
Anyway, i obviously listened to your advise, i’d be a stubborn fool if i didn’t, but it hasn’t worked. Something is stopping my item from reporting to the “Gateway1-out/3/3/1/0/2” topic. Is there some log that i can monitor to see what is going on here, do i need to add any sort of debugging commands to get it to save its processes to logs?
Please excuse me if i’m being dumb here but, how does OpenHab send an update to the MQTT topic for the switch to know if the light has changed if there is no outgoing on the switch topic in the item binding or no rules instructing an update or anything? The only entry for this topic is on this item in question and that is an incoming connection instructed by the “<” at the start of the topic.
It’s usually not this difficult to get the MQTT binding to subscribe and publish. The goal, as I understand it, is to define a single Switch item that will:
- Publish “1” to a topic when you turn it on in the UI:
>[mymosquitto:Gateway1-in/4/1/1/0/2:command:ON:1] - Publish “0” to a topic when you turn it off in the UI:
>[mymosquitto:Gateway1-in/4/1/1/0/2:command:OFF:0] - Subscribe to state changes and change the state of the Switch item when something publishes “0” or “1” to a topic:
<[mymosquitto:Gateway1-out/3/3/1/0/2:state:MAP(1on2off.map)], where the filetransform/1on2off.mapcontains:
0=OFF
1=ON
So you take the above three clauses, separate them with commas, and put them inside the quotes of mqtt="".
Then, in order to prevent openHAB from updating the state of the switch just when you toggle in the UI, you add , autoupdate="false" in the binding config as well.
You can add:
<logger name="org.openhab.binding.mqtt" level="TRACE"/>
to your logback.xml file in order to create verbose logging for the binding into your openhab.log file, but if you have done all of the other testing with mosquitto_sub, have your binding configured correctly in openhab.cfg, and everything else the wiki page describes, I don’t see how all that logging will help, because it ought to work.
I feel that I have to bow out of this thread now, with so many other things I need to tend to, but I wish you the best success! Regards, John