@watou - Just to inform you, i think i have found the reason your method wasn’t working. My light switch is programmed to go to sleep once it has sent its message to my gateway (MQTT publisher). This would be the reason that the item can’t send the state of the light back to it. I’m sorry for forgetting this vital information :(. I’m now going to have to resort back to the rule method.
I have gotten the situation working as it should be through rules and an extra Item. So below is my configuration for anyone interested:
Items:
Number CinemaRoom_onboardSwitch01 "Cinema Room Lighting onboard Switch [MAP(1on2off.map):%s]" <light> (SF_CinemaRoom) {mqtt="<[mymosquitto:Gateway1-out/4/1/1/0/2:state:default]"}
Number CinemaRoom_Switch01 "Light Switch [MAP(1on2off.map):%s]" <shield> (SF_CinemaRoom, gSwitch) {mqtt="<[mymosquitto:Gateway1-out/3/3/1/0/2:state:default]"}
Switch CinemaRoom_Light01 "Ceiling Lights" <light> (SF_CinemaRoom, gSwitch, gLight) {mqtt=">[mymosquitto:Gateway1-in/4/1/1/0/2:command:ON:1], >[mymosquitto:Gateway1-in/4/1/1/0/2:command:OFF:0], <[mymosquitto:Gateway1-out/4/1/1/0/2:state:MAP(1on2off.map)]", autoupdate="true"}
Rules:
rule "Cinema Room Light Toggle"
when
Item CinemaRoom_Switch01 changed
then
if (CinemaRoom_Light01.state == ON){
sendCommand(CinemaRoom_Light01, OFF)
} else {
sendCommand(CinemaRoom_Light01, ON)
}
end
rule "Cinema Room Light State Sync"
when
Item CinemaRoom_Light01 changed
then
if (CinemaRoom_Light01.state == ON){
CinemaRoom_onboardSwitch01.postUpdate(1)
} else {
CinemaRoom_onboardSwitch01.postUpdate(0)
}
end
My issue was, as stated by Rikoshak & Watou, that OpenHAB did not know the state of the relay module when it had been toggled by the on board switch, the module outputs a message on a MQTT topic, so i have made a rule and a item for this topic to assign it as a number, and then set a rule to update the light status accordingly if the topic of the on board switch has changed.
Thanks all for your assistance, very much appreciated.
I have learnt a lot from this issue, so thank you for not just solving the issue for me, but telling me what was wrong and leaving me to solve it for myself.
For some reason this has started to become an issue again, even though the solution has been working since this topic was left.
Any ideas why its occured again even with the rule inplace?
Are you still having troubles? I think this needs to be resolved in a very systematic way. Can you tell us what messages are being sent to the mqtt topics when (include all messages from either node):
- You press/toggle the switch a couple times.
- You press the onboard switch a couple times.
- You press the switch once when it is in an in-sync state, press the onboard switch once so it is out of sync, and then press the switch again until it is back in sync.
We need to know what messages are getting to mqtt from the MySensors modes before we even worry about trying to use openhab to control them.
Currently, i’m still experiencing these issues. I can get you those details within the next 24 hours, i’m currently out at the moment and pretty busy, but i will get the data and post it here as soon as i can.
Would you like me to delete the rules and then give you the data or leave the rules intact?
Thank you.
Whenever you’re able to get to it is fine. Please not that I added a #3 to the list up above.
At this point I don’t think you need to do anything with the rules. What I’m wanting to help you do is debug everything step by step. Here’s a rough idea of what we need to do overall:
- Determine what mqtt signals the mysensors nodes are sending.
- Make sure that the signals are getting into openHAB in a usable state.
- Based on #1 and #2, determine what the rules need to do and write them.
The data I asked for above was purely for step #1 and we are not even considering openHAB at this point.
Okay, so i’ve managed to get into my MQTT server and watch for the messages…
Lets start with the wall switch then:
mosquitto_sub -t Gateway1-out/3/3/1/0/2
1
0
1
0
Not that it matters for this troubleshooting step, but the light is on the opposite state, so when this shows 1 its off. This is due to the not switch on the first toggle (which is why i wrote the rule i did before to correct this, and it worked for a while).
Now for the on board switch:
mosquitto_sub -t Gateway1-out/4/1/1/0/2
1
0
1
0
For your third request of “You press the switch once when it is in an in-sync state, press the onboard switch once so it is out of sync, and then press the switch again until it is back in sync.” the output on the switch topic is exactly the same as i provided up above, the MQTT messages are showing the exact same no matter the state of the switch/light.
Ok, that’s a good start. I was hoping to see the responses of both topics for #3. Is it safe to assume that #3 does something like this?:
1 (off) Gateway1-out/3/3/1/0/2 - switch off
0 (off) Gateway1-out/4/1/1/0/2 - light off
0 (on) Gateway1-out/3/3/1/0/2 - switch on
1 (on) Gateway1-out/4/1/1/0/2 - light on
Now press the onboard switch
0 (off) Gateway1-out/4/1/1/0/2 - light off
Now press the wall switch again
1 (off) Gateway1-out/3/3/1/0/2 - switch off
The onboard switch probably doesn't send a message, but it would be:
0 (off) Gateway1-out/4/1/1/0/2 - light off
Now press the wall switch again
0 (on) Gateway1-out/3/3/1/0/2 - switch on
1 (on) Gateway1-out/4/1/1/0/2 - light on
Based on how you’ve described the switch behaviors above, I would guess this is what you see for both topics. Is this accurate?
It just occurred to me, the two nodes probably don’t communicate without the openHAB rule already running, do they? If so, it would be good to know what mqtt messages are sent to the nodes as well as which ones come from the nodes.
They should communicate as my item has a update rule there to post a message to the topic for the gateway listening.
This makes me wonder about number 3 again now. Maybe i should get multiple subscribes running on all the topics and see what is being sent once i press the light switch when its synced AND when it isn’t synced, as that is where i do believe the issue to be. I think that the first time i press the switch when it isn’t synced, then the message is either sending a value that the light is already sitting with OR the message doesn’t get sent the first time and only updates the value inside of OpenHAB…
I will get these values for you in the morning as i’v only just got in and i need to eat and get to sleep for another early morning.
Thank you for helping me though Jonny, i really appreciate this!
Yeah, it would be good to get a log of all the mqtt messages that are being
sent in these scenarios.
You can use a wildcard to subscribe, so you shouldn’t need to subscribe to
too many topics. Maybe just Gateway1-out/# and Gateway1-in/#. If you don’t
have too many other nodes yet, these ought to do the trick.
I have 3 topics and rather me explain each, i will insert the items file section below so you can see for yourself what i have.
Number CinemaRoom_onboardSwitch01 "Cinema Room Lighting onboard Switch [MAP(1on2off.map):%s]" <light> {mqtt="<[mymosquitto:Gateway1-out/4/1/1/0/2:state:default]"}
Number CinemaRoom_Switch01 "Light Switch [MAP(1on2off.map):%s]" <shield> (SF_CinemaRoom, gSwitch) {mqtt="<[mymosquitto:Gateway1-out/3/3/1/0/2:state:default]"}
Switch CinemaRoom_Light01 "Ceiling Lights" <light> (SF_CinemaRoom) {mqtt=">[mymosquitto:Gateway1-in/4/1/1/0/2:command:ON:1], >[mymosquitto:Gateway1-in/4/1/1/0/2:command:OFF:0], <[mymosquitto:Gateway1-out/4/1/1/0/2:state:MAP(1on2off.map)]"}
When i press the downstairs switch when its not synced, this is what all 3 topics are doing:
mosquitto_sub -t Gateway1-out/4/1/1/0/2
mosquitto_sub -t Gateway1-out/3/3/1/0/2
1
mosquitto_sub -t Gateway1-in/4/1/1/0/2
1
0
As you can see, the on-board switch doesn’t change, exactly as expected if i don’t touch that switch. So we can rule out any messages being sent there for no reason. The issue we see now, the light have not come on because of the light switch not being in sync with the light. This is shown in the light topic, its sitting at a 1 when the lights were off. So, this is showing that the light itself is not updating the topic when it is switched by the light switch on board.
I believe that the issue is that the light switch on board the light module is doing its job, but its not giving MQTT and then therefor OpenHAB any information of what state the light is in.
I’m not too sure if the light topic itself should be updating on the Gateway1-in/4/1/1/0/2 topic when the onboard switch is used though as this is a topic that the mysensors listens to for commands, not publishes to update the controller. The topic that the controller is listening on to keep updated on the state would be the Gateway1-out/4/1/1/0/2 i think.
Ok, this is getting somewhere. It would be helpful for me to wrap my mind around things if I see the order of the mqtt messages. Can you do this test again with the following mqtt sub command?
mosquitto_sub -v -t Gateway1-out/4/1/1/0/2 -t -t Gateway1-out/3/3/1/0/2 Gateway1-in/4/1/1/0/2
The -v is for verbose, which prints the topic name and then the payload. This will allow us to see all of the messages in the order they were published.
I have a few questions that I want to ask just to confirm that some assumptions I’m making are accurate:
- Is the onboard switch a toggle? (i.e. you just push it the same way to turn it on and off, there is not a separate on position and off position)
- Is the wall switch a toggle?
- When you say “downstairs switch”, which one is that? We should decide on a consistent name for each. Does “onboard switch” and “wall switch” work? If you have better names, I will use whatever you think is best.
- Can you post the openHAB rules that you currently have related to this?
One thing that I found interesting is that you really only have two topics here. Is there not a separate topic for the onboard switch and the light? If that’s the case, then for all practical purposes the only state we need to keep track of is the light I think. The onboard switch is basically a direct control of the light’s state, and the state of the light when it changes is all that we really want to report to openHAB. Don’t do it yet, but after we figure out how to fix the situation you could probably get rid of the onboard switch openHAB item since the light state is what you actually care about.
I’m looking forward to solving this! 
So with the wall switch no in sync, i have subscribed to the topics as you stated and i got the following from 3 presses of the wall switch. The first is bringing it back into sync, then the next two are turning it on and then off. That was the plan anyway. It turned out that the light is on after 3 presses this time.
mosquitto_sub -v -t Gateway1-out/4/1/1/0/2 -t Gateway1-out/3/3/1/0/2 -t Gateway1-in/4/1/1/0/2
Gateway1-in/4/1/1/0/2 0
Gateway1-out/3/3/1/0/2 1
Gateway1-out/3/3/1/0/2 0
Gateway1-out/3/3/1/0/2 1
Gateway1-in/4/1/1/0/2 1
Gateway1-in/4/1/1/0/2 1
Gateway1-in/4/1/1/0/2 1
To answer your questions:
-
The on board switch is a momentary switch, a normal light switch. The rocker style. Like such: https://www.beststuff.co.uk/store/images/D/FBS43.jpg
-
The wall switch is the same, a momentary switch. This time its a small little round button that you push in and it latches and locks in, then press again to release. Just like a rocket switch basically.
-
We can use two names as you said, sorry my bad for confusing matters. Wall switch is the downstairs (in my office) and the on-board switch is the switch connected to the module directly.
-
The rules are as below:
rule "Cinema Room Light Toggle"
when
Item CinemaRoom_Switch01 changed
then
if (CinemaRoom_Light01.state == ON){
sendCommand(CinemaRoom_Light01, OFF)
} else {
sendCommand(CinemaRoom_Light01, ON)
}
endrule "Cinema Room Light State Sync"
when
Item CinemaRoom_Light01 changed
then
if (CinemaRoom_Light01.state == ON){
CinemaRoom_onboardSwitch01.postUpdate(1)
} else {
CinemaRoom_onboardSwitch01.postUpdate(0)
}
end
I completely agree with you here, this is how i was entially thinking about doing this but then others around here told me otherwise. I don’t care and OpenHAB shouldn’t need to care about what state the on board switch is, only what the light is. I mean, in my head, openhab shouldn’t care what state my wall switch is really, all that matters is IF the state of the wall switch changes, then change the light state. Doesn’t have to match, the light doesn’t need to match the wall switch, just toggle when the switch is toggled. I will dig out the post where someone was pretty adamant that i needed to sync it all together, which is just not needed in my opinion. However, I may be wrong!
Ok, I think what you were saying for questions one and two are:
- The onboard switch has a separate on position and off position.
- The wall switch has a separate on position and off position.
Is that correct?
I skimmed this thread a few weeks ago and know the posts you are talking about. If you need to know the state of the switches in openHAB, then you need to track each switch. In the context, I believe it made sense. Since we’re basically starting from square one, we have an opportunity to change things if it’s clearer.
Alright, I’m trying to gather information on how everything works a piece at a time. Just so we can fully see everything that’s going on, can you post either the sketches or the links to the sketches on your two mysensors nodes?
Those assumptions are correct.
Yeah, a nice clean fresh start would be great.
The sketches are:
www.matthews235.co.uk/files/gateway.ino
www.matthews235.co.uk/files/wallswitch.ino
If you for some reason need the files that are included for the mysensors, i can zip the whole folder and give that too you. Thats my personal FTP account so may just remove those links at some point so my address isn’t floating around. I will give you enough time to get the files if i do decide to though.
Very nice. No, I don’t need the mysensors code. Just your sketches should be good.
Is the gateway.ino the same as your node with the light actuator? Or do you still need to share that one?
I’ll check these out more closely this evening after I’m done working.
I forgot about the light itself. If you look at the “relay with button” sketch on this link, https://www.mysensors.org/build/relay, it should be somewhat a like that. That is a newer version to the ones i’m running i think. I will get my exact file uploaded tomorrow morning for you. Sorry about that.
Ok, I looked at your sketches. I’m going to make some observations, and then give some code that I suggest to make everything work as you want it to.
- The wall switch does exactly what I would expect: send a different state every time you switch it.
- When the light node receives a message, it sets it to whatever value it receives. If it is already off, and it receives an off message, it will stay off. This is probably why you see the “out of sync” errors.
- I’m a little confused about part of the light node code. It sends an update with the following code:
void loop()
{
debouncer.update();
// Get the update value
int value = debouncer.read();
if (value != oldValue && value==0) {
send(msg.set(state?false:true), true); // Send new state and request ack back
}
oldValue = value;
}
- I’m not sure why the “value==0” part is there, but if I’m reading it correctly it may only send updates when the light is turned off. I’m not familiar with the bounce2 library, so that may not be what it’s doing. I glanced at the library documentation and it seems like that’s what it is doing though. We may need to tweak this sketch’s code if it causes problems. It could be a problem because it’s important that we know the state of the light.
- We can update the item definitions and update the rule, then see how it works, and tweak from there if needed.
Now, for the updates to your files. My first thought is that we should use switch items to represent the ON/OFF states of switches/lights. It just seems to be the best fit. To help with that, we’ll use maps. Create these two map files:
0On1Off.map
-=
0=ON
1=OFF
0Off1On.map
-=
0=OFF
1=ON
Off1On0.map
OFF=1
ON=0
Next we’ll update the Items definitions:
Switch CinemaRoom_Switch01 "Light Switch [%s]" <shield> (SF_CinemaRoom, gSwitch)
{mqtt="<[mymosquitto:Gateway1-out/3/3/1/0/2:state:MAP(0Off1On.map)]"}
Switch CinemaRoom_Light01 "Ceiling Lights [%s]" <light> (SF_CinemaRoom)
{mqtt="<[mymosquitto:Gateway1-out/4/1/1/0/2:state:MAP(0On1Off.map)],
>[mymosquitto:Gateway1-in/4/1/1/0/2:command:*:MAP(Off1On0.map)]"}
This setup uses maps to convert the 1s and 0s to ONs and Offs, and vice versa. Note that the maps used for CinemaRoom_Light01 have 0 mapped to ON and 1 mapped to OFF like you described above. Also, instead of using multiple outgoing mqtt messages like you had before, we use a .map file to make it so we only need one outgoing configuration.
Now the rule:
rule "Cinema Room Light Toggle"
when
Item CinemaRoom_Switch01 changed
then
if (CinemaRoom_Light01.state == ON){
sendCommand(CinemaRoom_Light01, OFF)
} else {
sendCommand(CinemaRoom_Light01, ON)
}
end
I believe this is the only rule you will need. Like you said, whenever the switch changes, you want the light to switch to the opposite state. This requires that you know the current state of the light, but other than that we don’t need any additional information. The main assumption here is that the light node always sends the correct state back to the controller. The onboard switch doesn’t actually send a message or receive messages, so there is no need to attempt to track the onboard switch state.
Let me know how it works or if you have questions. If it doesn’t work, it would probably be best to share the following so we can debug:
mosquitto_sub -v -t Gateway1-out/4/1/1/0/2 -t Gateway1-out/3/3/1/0/2 -t Gateway1-in/4/1/1/0/2
tail -f {openhab dir}/logs/events.log
I’m sorry, i didn’t realize you had replied, for some reason my email notification didn’t come through.
Before I moved my openhab setup to my Dell Rack Server, i had it sitting on a raspberry pi, and that was working perfectly fine with the exact setup that i’m running with right now. The rules, sitemap and items were exactly the same. I have just loaded my Pi up and its working perfectly fine on that still. I’m having a quick check that it is all working the same, i fear the MQTT or the openhab section is incorrect, not the config files. I will have a quick look over these and if i still have no joy i will attempt what you have given me. I’m just a little confused to why it works on one machine but not the other, maybe a permission issue or something. Not too sure right now.
Thank you for your help, i will update you later on today with what is happening my end.
Again, sorry for the late reply.
Thanks,
Sam.