With my iPhone, I can be in the same room, the blinds 12’ away or so. I could definitely have RF interference.
In openHAB I am going to test the command was received and if not do a retry. My ESP is only a couple of feet away from the blinds I am working on.
BTW thanks for you help with all of this. Really like the OMG device!
Hi Chris. If you can tell me how to receive order returns in OpenHab, I’m interested.
Hi @Dom76
Do you see the reply messages at all when monitoring your device MQTT messages History with MQTT Explorer?
As suggested above, create a thing with the complete received message(s) from your Blind Tilt, e. g.
Type string : mqtt_message "MQTT Message" [ stateTopic="home/OMG_ESP32_BLE5/BTtoMQTT/D93130B40608" ]
This also shows that is is important to always replace the generic OpenMQTTGateway name in in the decumentaiton example with your uniquely renamed OMG gateway name, just in case you might have stumble across this one when trying my suggestions above.
Create a related item
String OMG_ESP32_BLE5_message {channel="mqtt:topic:OMG_ESP_ D93130B40608: mqtt_message"}
Then have a rule, DSL as an example
rule "Receive OMG_ESP32_BLE5 MQTT message Rule"
when
Item OMG_ESP32_BLE5_message changed
then
val String msg = (OMG_ESP32_BLE5_message.state as StringType).toString
if(msg.toString.contains("tilt")) {
// Do whatever and however you want to process a received successful response message containing the "tilt" key
}
end
Hope this helps in you getting closer to being able to deal with response messages.
Just quickly cobbled together here, so might be some typos included
No, I don’t see anything in return for my commands in the history. I’m going to create the thing, its item and the rule and I’m going to do the tests by deleting the blind tilt from the SwitchBot application.
I look at the open value.
{"id":"D7:06:35:DF:59:0D","rssi":-63,"brand":"SwitchBot","model":"Blind Tilt","model_id":"W270160X","type":"WCVR","open":100,"direction":"—","motion":false,"calibrated":true,"lightlevel":2,"batt":98,"mac":"D7:06:35:DF:59:0D"}
I send the command to open the blind. 10 seconds later I expect open to be a value of 100 and of course 0 when I close the blind. Otherwise I consider it has failed.
Are you seeing any response messages at all in the MQTT messages history in MQTT Explorer for the Blind Tilt?
Obviously only when successful
Yes.
{"id":"D7:06:35:DF:59:0D","tilt":50,"open":100,"direction":"-"}
I use the expire function on my switch to open or close the blind. {expire=“10s,state=OFF”} So when it switches to off I check the open value. That should take care of any delay in executing the command. My code looks pretty clunky but it is working.
Thanks for the confirmation.
@Dom76 Best to scroll through your MQTT messages history again, I’m sure you will find yours as well, especially shortly after a successful command has been sent.
Expire is also a good way of regularly checking for the response status, so I assume you reset the state to On again if still ne response has been received to keep checking
I still think that this might be the root cause for failed commands to the Blind Tilt foremother source like OMG, so deleting it from the app and the hub hopefully will make it reliably responsive for commands.
well I was finally able to see the return command when it is executed correctly. I disconnected my blinds from the app and the Hub, it is better but not yet immediate, I have to send the command several times before it is executed. I have several ESPs installed (4) in different places in the house to cover all the areas where the sensors are located, can this influence?
Currently it depends to which gateway you are sending the command, as it is solely this particular gateway to broadcast the command. So if you are sending it to one of your gateways which is farthest away from the Blind Tilt you want to control, it might not work too well because of the distance.
At the moment it is best practice to send the commands to the closest gateway of the device you want to control. Which could mean sending commands through different gateways depending on the targeted device.
We are already planning to implement a gateway sync, similar to the device tracker sync, so that each command is automatically sent by the closest gateway of the device the command is meant for, no matter to which gateway it was issued.
ok that’s what I do, the command is sent to the gateway in the same room. however I noticed that although I receive a response to my command, the command is not executed here is a screenshot.
I am a bit confused with the screenshot. I can see the response at 12:54:05 with tilt:25 and open:50, and the not matching state message with open: 80, but I also see a selected response message with tilt:60, open:80 and direction: up, which does correspond with the latest state message
How are you sending the individual, not fully closed either way or fully open, commands with individual tilts?
I know I asked you to remove the Blind Tilt from the app and hub, but I do take it that you have your Blind Tilt on the latest firmware when you previously used the app - just to make sure.
I think it was a display bug in MQTT explorer.
I’m not sure I understand your question.
And yes my firmware is up to date with version v2.3
So was this one of the cases that sending the command didn’t work on the actual Blind Tilt, i. e. the Blind Tilt didn’t move and change at all, and OMG then received and published the state with what you are seeing in the top message - which looks like a setting of a prevo=ious command you sent, as indicated by the previous response message still being deleted and showing up at the bottom of the message diff display?
Which makes me assume that sometimes sending the command works fine, as indicated by a correct response message AND the Blind Tilt actually moving, while other times sending a command, even though it produces a successful response message, which OMG should only really do if it receives a correct response, BUT even though it sends out a confirmation response to a command the actual Blind Tilt device doesn’t move at all. This would be very indicative and similar to what @badhairday described seeing even with the native app on his phone, and is very likely due to a bug still existing with the Blind Tilts.
The fact that there seems to be response confirmations being received by the Blind Tilt, even if it actually doesn’t execute the commands sometimes, makes it virtually impossible to reliably use any response message for command execution confirmation or having to resend
I would test and observe the command - response - actual Blint Tilt behaviour a bit more with MQTT Explorer, to see if you might see any logic behind its behaviour.
I did quite a few tests today and the first observation was that the commands sent with the terminal on my MAC work more regularly than the commands sent in a rule via the action of an Inter.
Attached is the rule I use.
In my rule I restart the update of the switch if the “open” position value is not reached to return the command and I add a StoreStopLoop switch to stop the loop in the case where the command does not is never executed (it happens)
rule “store bureau gauche OPEN/CLOSE”
when
Item Store_bureau_gauche received update
then
if ((Store_bureau_gauche.state == ON) && (StoreStopLoop.state ==OFF)){
StoreSendCMD.sendCommand('{\"model_id\":\"W270160X\",\"tilt\":\"open\",\"id\":\"F7:98:3F:54:57:78\"}') // bureau gauche OPEN
timer = createTimer(now.plusSeconds(5), [ |
if (StoreBureauGRoller.state != 100) {
Store_bureau_gauche.postUpdate(ON)
sendBroadcastNotification("relance store gauche ON")
}
])
}
if ((Store_bureau_gauche.state == OFF) && (StoreStopLoop.state ==OFF)) {
StoreSendCMD.sendCommand('{\"model_id\":\"W270160X\",\"tilt\":\"close_down\",\"id\":\"F7:98:3F:54:57:78\"}') // bureau gaucheCLOSE
timer = createTimer(now.plusSeconds(5), [ |
if (StoreBureauGRoller.state != 0) {
Store_bureau_gauche.postUpdate(OFF)
sendBroadcastNotification("relance store gauche OFF")
}
])
}
end
I did quite a few tests today and the first observation was that the commands sent with the terminal on my MAC work more regularly than the commands sent in a rule via the action of an Inter.
Attached is the rule I use.
In my rule I restart the update of the switch if the “open” position value is not reached to return the command and I add a StoreStopLoop switch to stop the loop in the case where the command does not is never executed (it happens)
rule “store bureau gauche OPEN/CLOSE”
when
Item Store_bureau_gauche received update
then
if ((Store_bureau_gauche.state == ON) && (StoreStopLoop.state ==OFF)){
StoreSendCMD.sendCommand('{\"model_id\":\"W270160X\",\"tilt\":\"open\",\"id\":\"F7:98:3F:54:57:78\"}') // OPEN STORE
timer = createTimer(now.plusSeconds(5), [ |
if (StoreBureauGRoller.state != 100) {
Store_bureau_gauche.postUpdate(ON)
sendBroadcastNotification("relance store gauche ON")
}
])
}
if ((Store_bureau_gauche.state == OFF) && (StoreStopLoop.state ==OFF)) {
StoreSendCMD.sendCommand('{\"model_id\":\"W270160X\",\"tilt\":\"close_down\",\"id\":\"F7:98:3F:54:57:78\"}') // CLOSE STORE
timer = createTimer(now.plusSeconds(5), [ |
if (StoreBureauGRoller.state != 0) {
Store_bureau_gauche.postUpdate(OFF)
sendBroadcastNotification("relance store gauche OFF")
}
])
}
end
That makes it even more confusing for me but just for clarification
• When you say you send the same command in Terminal on your Mac, you do mean you send the same command syntax to the MQTT broker by publishing it there?
• And not sending any direct raw service/characteristic command directly to the Blind Tilt through your Mac’s in built Bluetooth?
A third option would also be publish the command in the Publish section of MQTT Explorer, with something like
But with all three options sending the same command to the MQTT broker, and OpenMQTTGateway receiving the command from the broker, and OMG not even being able to differentiate where the command is coming from, from openHAB, macOS Terminal or MQTT Explorer, there should not be any different success rates for any of the three. And you can also check any incoming command in the commands > MQTTtoBT sub-topic of your gateway, also with its own history.
So, clear the history, send 10 commands through openHAB, view the history to see if all 10 commands have been received by OpenMQTTGateway.
Clear the history again and repeat with MQTT Eplxorer’s Publish section and macOS Terminal.
Best to also note if all 10 commands have successful response messages in the Blind Tilt topic, and if every successful response message also made it actually move or not. So best to alternate each command with "tilt":"close_up",
and "tilt":"open"
, to be able to see that, and wait for every successful moving to be fully finished before issuing the next command.
All three possibilities should have them sent each and very command successfully to OpenMQTTGateway, and your above observation might just have been wishful anticipation
English please, this is an international community!
Concerning sending commands via the terminal, it is indeed to the Mqtt mosquitto broker that I send them.
I will do the tests that you described. Unfortunately I will not be able to do them before next Monday. I will keep you informed
Looking forward to your test results.
In the meantime I’d also like to as you and @badhairday to post your gateway’s BTtoMQTT settings message. Just to see if any setting there might affect the intermittent commands, which it shouldn’t really and also wouldn’t explain badhairday’s problems with using his phone with the app for commands, but won’t do any harm either to have look at them.