Yeah sorry, I read your sitemap incorrectly as I was confused by “Always all four turn on or off at the same time in the BasicUI.” your first post. I was thinking you were using the group item as a single switch, in which case it made sense that all four turn on/off at once in BasicUI.
So just to make sure we’re on the same page, when you toggle Switch3 in BasicUI to ON, all four of the switches change to ON. However, on the actual device, only POWER1 and POWER3 turn on. Is that correct?
This is my first tasmota switch which is using rules in the configuration.
But it works all right if I give the following statement in teh Tasmota console:
cmnd/plug/tasmota/19/POWER3 ON
Then only socket 3 turns on.
In my mqqt spy I receive only the result topics. I don’t receive anything listing to the cmd topic. But the switch is working:
Rule1 ON Button1#State DO Power4 2 ENDON
Rule1 1
Rule2 ON Analog#range<22 DO Power3 2 BREAK ON Analog#range<46 DO Power2 2 BREAK ON Analog#range<73 DO Power1 2 ENDON
Backlog Rule1 1; Rule2 5
Here is what happens when I use the console with the commands Rule, Rule1, Rule2, Backlog:
13:32:33 CMD: Rule
13:32:33 MQT: stat/plug/tasmota/19/RESULT = {"Rule1":"ON","Once":"OFF","StopOnError":"OFF","Free":477,"Rules":"ON Button1#State DO Power4 2 ENDON"}
13:32:47 CMD: Rule1
13:32:47 MQT: stat/plug/tasmota/19/RESULT = {"Rule1":"ON","Once":"OFF","StopOnError":"OFF","Free":477,"Rules":"ON Button1#State DO Power4 2 ENDON"}
13:32:50 CMD: Rule2
13:32:50 MQT: stat/plug/tasmota/19/RESULT = {"Rule2":"ON","Once":"ON","StopOnError":"OFF","Free":401,"Rules":"ON Analog#range<22 DO Power3 2 BREAK ON Analog#range<46 DO Power2 2 BREAK ON Analog#range<73 DO Power1 2 ENDON"}
13:34:38 CMD: Backlog
13:34:38 MQT: stat/plug/tasmota/19/RESULT = {"Backlog":"Empty"}
This happend in the event.log when I change PlugT19_Switch3 in the BasicUI from OFF to ON:
2020-05-03 13:37:17.112 [ome.event.ItemCommandEvent] - Item 'PlugT19_Switch3' received command ON
2020-05-03 13:37:17.132 [nt.ItemStatePredictedEvent] - PlugT19_Switch3 predicted to become ON
2020-05-03 13:37:17.143 [vent.ItemStateChangedEvent] - PlugT19_Switch3 changed from OFF to ON
2020-05-03 13:37:17.224 [vent.ItemStateChangedEvent] - PlugT19_Switch2 changed from OFF to ON
2020-05-03 13:37:17.225 [vent.ItemStateChangedEvent] - PlugT19_Switch1 changed from OFF to ON
2020-05-03 13:37:17.225 [vent.ItemStateChangedEvent] - PlugT19_Switch4 changed from OFF to ON
In the BasicUI also all 4 switches Turn ON? It should only turn switch 3 ON.
In the Tasmota Console it looks like this:
13:37:16 MQT: stat/plug/tasmota/19/RESULT = {"POWER1":"ON"}
13:37:16 MQT: stat/plug/tasmota/19/POWER1 = ON
13:37:16 MQT: stat/plug/tasmota/19/RESULT = {"POWER3":"ON"}
13:37:16 MQT: stat/plug/tasmota/19/POWER3 = ON
The device turns socket 1 and socket 3 to ON.
It should only turn socket 3 to ON.
Okay, openHAB will try to publish one message for that.
From your Things, that should be to topic cmnd/plug/tasmota/19/POWER3 with a payload ON
You say you cannot see that in mqqt spy
But we know that something is published, because the tasmota reacts.
Either
openHAB publishes to a different topic - use mqtt.spy to find out.
Or
openHAB publishes to a different broker than the one you are looking at.
I think this the first mystery I would try to solve.
Once you know what arrives at the tasmota, you can begin to wok out why it doesn’t do what you expect. Can’t you see incoming topics/payloads on the tasmota console?
Reference the rules, your statement sounded as if you would be using openHAB rules. You do not do that and IMHO your tasmota rules do not relate to the observed problem.
Regarding the messages on the tasmota console you see ( and don’t see) when switching via BasicUI, are you using only mqtt commands? When switching via a http command, I do see only the MQTT stat message!
So the plug behaves correct to turn socket 1 and 3 to ON because there are actually 2 cmds.
So there is an error in my Thing or Item configuration which I didn’t change since my first post here.
Check that you have not defined Things in both PaperUI and xxx.things files.
Assuming you’ve only created your Things in files, and you have checked that you do not have two files with near-duplicate Thing definitions - reinitialise the binding so that it is not using older edited versions of your Things. (reboot openhab if you do not know how to do that). Bindings can sometimes not fully pick up edits of Things until a restart.
Ours of your and my time and the only thing needed was a restart. Maybe from reasons Rossko57 was mentioning. There is and was only one Thing file but it seems the binding didn’t get the changed correctly.
In this case it looks to me that openHAB is somehow configured to send the power ON to all switches ( the items all switch to ON), but only the mqtt messages get through.
Why only the “predicted” message is logged might be a further indication, however I can’t tell the reason for that.
Hi helipus, how did you flash this device? I could not find any information on the flashing process for this device via Google.
Did you just soldered wires to TX and RX and flashed a basic Tasmota firmware to it? And then used the template from Gosund P1 Power Monitoring Power Strip (P1) Configuration for Tasmota to configure the Tasmota to the device?
Thanks!
Hi Frank,
You don’t need to solder. I flashed all my Tuya chip products which before ran in Smart Life with the same process via the software Tuya converter which ran under a unix installation with an wifi adapter.
You can run it either on your raspi or you can use a Live Ubuntu or Kali image with your can boot from an USB Stick on your windows computer. I used the Live USB Stick.
In case it helps, we also have a tutorial here in the openHAB community.
I ran Tuya-convert on my RPi using a spare SD card with a fresh Raspbian install. Later on, I put that image on a second RPi to run Pi-Hole and CUPS, so now I have it available any time I need to flash a new Tuya device.
