letscontrolit / ESPEasy

Easy MultiSensor device based on ESP8266/ESP32
http://www.espeasy.com
Other
3.22k stars 2.2k forks source link

switch light: domoticz mqtt integration #3544

Open megamarco833 opened 3 years ago

megamarco833 commented 3 years ago

hi, i was with espeasy build ESP_Easy_mega-20200204_normal_ESP8266_4M1M.bin on nodemcu the system has this generic setup:

scope: switch on/off the light using wall switch and use domoticz as well to control the status of the light and switch on/off also the light from domoticz.

i create a script in domoticz that when i turn off/on the idx=96 send an mqtt message: if ON it send => dz2esp_kitchen 1 if OFF it send => dz2esp_kitchen 0

inside espeasy i create a "dummy Generic - MQTT Import" named as "sniff" like this: immagine immagine

then i set up a rule:

On System#Boot do    //When the ESP boots, do relay to OFF just to be sure
  gpio,13,1 //kitchen
  gpio,14,1 //bathroom
endon

on wall_kitchen_1#Switch do
      Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "Toggle" }' // id of kitchenLight
endon

on wall_kitchen_2#Switch do
      Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "Toggle" }'
endon

on sniff#kitchen=1 do gpio,13,0 
on sniff#kitchen=0 do gpio,13,1 
endon

so when i turn idx=96 ON domoticz send: dz2esp_kitchen 1 espeasy rule will set GPIO13 0 (inverted relay) and relay will trigger ON

if i use push button (wall switch) rule will recognize the status change and send to domoticz: Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "Toggle" }' // id of kitchenLight

of course this is a workaround beacuse mqtt for switch and domoticz doesn't talk properly (i should use domoticz help task, but it will require a task for every relay and it do not manage inverted relay) but this configuration as workaround was working till now.

Now i have upgraded my esp with latest espeasy firmware, but this configuration is not anymore working! ;( i see that with new firmware i receive a "ping-pong" message between domoticz and espeasy and relay is continuosy triggering on and off...and i see that domoticz is contiusoly sending the message dz2esp_kitchen 1 and dz2esp_kitchen 0 because espeasy recognize an wall_kitchen EVENT as status change (but i do not use the wall switch i just click on domoticz idx) and espeasy send the message `Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "Toggle" }' it will create this ping-pong message and the realy continue to loop on/off

Again this not happened with ESP_Easy_mega-20200204_normal_ESP8266_4M1M.bin i revert back and is working again. so my two question are: 1) why this happen on new firmware and not in previous ? 2) is not possibile to solve this situation and make working talking between switches on espeasy and domoticz with mqtt?

the scenario is simple: n°1 relay for light on GPIO 13 (1=off 0=on) n°2 wall switches as push button to control the relay n°1 domoticz dummy device idx=96 to control the relay and see the status of relay (if on or off)

how to have it with mqtt and avoid to use "domoticz mqtt help task"?

espeasy should recognize message public on topic: domoticz/out with message OFF: { "Battery" : 255, "LevelNames" : "Off|Level1|Level2|Level3", "RSSI" : 12, "SelectorStyle" : "0", "description" : "", "dtype" : "Light/Switch", "hwid" : "6", "id" : "000140B0", "idx" : 96, "name" : "kitchen", "nvalue" : 0, "stype" : "Selector Switch", "svalue1" : "0", "switchType" : "On/Off", "unit" : 1 }

message ON: { "Battery" : 255, "LevelNames" : "Off|Level1|Level2|Level3", "RSSI" : 12, "SelectorStyle" : "0", "description" : "", "dtype" : "Light/Switch", "hwid" : "6", "id" : "000140B0", "idx" : 96, "name" : "kitchen", "nvalue" : 1, "stype" : "Selector Switch", "svalue1" : "0", "switchType" : "On/Off", "unit" : 1 }

(look at idx, nvalue)

and accordingly trigger relay (GPIO13)

if you can implement this on firmware espeasy, if i trigger a push buton i can simple rule like this:

on wall_kitchen_1#Switch do
      Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "Toggle" }' // id of kitchenLight
endon

this will trigger idx of domoticz and domoticz will send the mqtt command on topic domoticz/out espeasy will receive it and will trigger accordingly the realy. what do you think? is it possible to implement / fix? thanks

tonhuisman commented 3 years ago

NB: This could have been a question for the Forum, as it is not a software fault, AFAICS

Now lets try to find a solution: Is it possible to change your relays to turn on when the GPIO is set to 1, and off when set to 0? If so you can most likely reduce your rules to just a single event handler for each buttons, and maybe keep the System#Boot event to initially turn off the relays, and the rest could be done using tasks and controllers in ESPEasy. I've been setting up my Sonoff S20's in that way (even though they only have 1 switch instead of 2 it could work with any count of buttons), but that doesn't matter, as you send the state of the relay to Domoticz using the Domoticz MQTT Controller, and receive the desired change from Domoticz using the Domoticz MQTT Helper plugin.

The rules for each button could then be as simple as this:

on ButtonX#State=0 do // multiple buttons can control a single light, if needed
  if [Relay#State]=0
    gpio,12,1 // Toggle state
  else
    gpio,12,0
  endif
endon

The Relay GPIO is configured as a Switch task, and connected to the Domoticz IDX for the light. The Domoticz MQTT Helper is listening to the same IDX, and GPIO. (But as you already discovered it is missing an 'inverted' option.) That works (very) nice for these Sonoff S20/S26 devices.

I haven't yet tried to use the Inverted option on the Relay task. I'll get back on that later.

TD-er commented 3 years ago

For Domoticz + MQTT + switch, please check the extensive example for it in the documentation Without the "Domoticz MQTT helper" plugin, it is next to impossible to get it right.

tonhuisman commented 3 years ago
on sniff#kitchen=1 do gpio,13,0 
on sniff#kitchen=0 do gpio,13,1 
endon

That looks a bit weird and is probably not working (anymore), and can be simplified to:

on sniff#kitchen do
  gpio,13,=!%eventvalue%
endon
megamarco833 commented 3 years ago

For Domoticz + MQTT + switch, please check the extensive example for it in the documentation Without the "Domoticz MQTT helper" plugin, it is next to impossible to get it right.

hi, that's fine, a configuration like this works with new firmware, but NOT with inverted relay ;( stupid question, why we need to use "Domoticz MQTT helperplugin? it means that every relay need one task of Domoticz MQTT helperplugin we have 8 tasks, so only 4 relay without any switch ;( it's not possible to improve the domoticz controller to avoid using of Domoticz MQTT helperplugin ? and again, with inverted ralay also this solution is not working

second part: why my configuration was perfectly working since quite a year till now, but with new firmware not? with new fw i have this "ping-pong" messages and relay that continue turn on/off ? i reverted back and without change nothing my configuration posted still working.

TD-er commented 3 years ago

There have been changes in the switch plugin which may cause it.

Since the Domoticz MQTT helper (and the Domoticz MQTT controller) does cooperate with only a few plugins, maybe we can have a look at how we can either extend the helper plugin to support multiple instances of that same plugin, or maybe extend the controller settings to mark some tasks to be dealt with differently. I do understand the side effects of the need for double or triple amount of plugins for doing relatively simple tasks.

Adding an invert option is a good addition for this plugin anyway.

megamarco833 commented 3 years ago

There have been changes in the switch plugin which may cause it.

ok, that's the reason :-) thanks! for me it's a bit strange that if i send a mqtt message that contain dz2esp_kitchen 1 or dz2esp_kitchen 0 it trigger also the event wall_kitchen_1#Switch that cause the continue activation/deactivatioin of relay

on wall_kitchen_1#Switch do
      Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "Toggle" }' // id of kitchenLight
endon

on previous version with mqtt message that contain dz2esp_kitchen 1 or dz2esp_kitchen 0 the event wall_kitchen_1#Switch was not responding, and on my understanding it was correct....

Since the Domoticz MQTT helper (and the Domoticz MQTT controller) does cooperate with only a few plugins, maybe we can have a look at how we can either extend the helper plugin to support multiple instances of that same plugin, or maybe extend the controller settings to mark some tasks to be dealt with differently. I do understand the side effects of the need for double or triple amount of plugins for doing relatively simple tasks.

Also here i full agree...i do not understand why we must have the helper plugin, on my idea it's better to integrate inside domoticz mqtt controller. but again, it's only my poor opinion, i'm most of all an user not a developer, so sorry for my (stupid) comments :) anyway, if it is possible to avoid the usage of helper plugin (al least if it's necessary should better have multiple instances inside only one task.

sorry for my ignorance, but why it's not possible to modify domoticz controller plugin and listen on topic: domoticz/out for messages like this: message OFF: { "Battery" : 255, "LevelNames" : "Off|Level1|Level2|Level3", "RSSI" : 12, "SelectorStyle" : "0", "description" : "", "dtype" : "Light/Switch", "hwid" : "6", "id" : "000140B0", "idx" : 96, "name" : "kitchen", "nvalue" : 0, "stype" : "Selector Switch", "svalue1" : "0", "switchType" : "On/Off", "unit" : 1 }

message ON: { "Battery" : 255, "LevelNames" : "Off|Level1|Level2|Level3", "RSSI" : 12, "SelectorStyle" : "0", "description" : "", "dtype" : "Light/Switch", "hwid" : "6", "id" : "000140B0", "idx" : 96, "name" : "kitchen", "nvalue" : 1, "stype" : "Selector Switch", "svalue1" : "0", "switchType" : "On/Off", "unit" : 1 }

in this way ,selecting the IDX inside the relay task espeasy can listen at domoticz/out topic only for idx selected and looking at nvalue (1 or 0) trigger accordingly the relay. if this could be implemented we have solved the issue.

if my proposal above could be implemented, also for pushbutton it will be easy menaged, a simple rule like:

on wall_kitchen_1#Switch do
       Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "Toggle" }' 
 //with a push pressing ( if above code could be implemented on domoticz controller plugin ) espeasy will send to domoticz toggle comand and domoticz will respond with message on domoticz/out and espeasy will trigger relay accordingly
endon

what do you think?

Adding an invert option is a good addition for this plugin anyway. yes it is. but if my proposal could above could work, and it is manageable for you, we just use the relay task where we have inside flag for inverted relay.

UPDATE: a work around could be implement in espeasy two controller: 1) HTTP domoticz controller 2) openhab controller where set on publishing controller: domoticz/in

inside domoticz we can set on dummy device that control the light: action on = http://192.168.0.153/control?cmd=GPIO,13,0 action off = http://192.168.0.153/control?cmd=GPIO,13,1

inside espeasy create a task for relay: select inverted, select GPIO13, select on first controller (http domoticz) idx=96 create a second task for push button: select active low, none idx create a rule like this:

on wall_kitchen_1#Switch do
Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "Toggle" }' // id of kitchenLight
endon

in this case when the command start from domoticz we use http controller and idx selected on relay task when the command start from push button we publish using openhab controller the mqtt on domoticz/in with idx to trigger and domoticz using http controller will trigger the GPIO selected on relay task

this is a workaround tested right now and works on latest firmware, but it's a workaround.... if my proposal of modify domoticz controller to listen at messages given as example could be implemented i think it will be much better and correct :) what do you think?

TD-er commented 3 years ago

I wil mark it for now as unread, so I will not miss it later when I have more time to reply to such a lengthy message.

megamarco833 commented 3 years ago

I wil mark it for now as unread, so I will not miss it later when I have more time to reply to such a lengthy message.

sorry to wrote such a long message :(

megamarco833 commented 3 years ago

I wil mark it for now as unread, so I will not miss it later when I have more time to reply to such a lengthy message.

hi @TD-er did you got time to think on it?

TD-er commented 3 years ago

There are several ways we can approach this.

To first clearify the latter, as that option was not yet mentioned. You can call GPIO command to set a GPIO pin (even via GPIO extenders), and you can also enable "monitor" on a pin (even via GPIO extenders) to get an event when a pin state has changed. In rules you can also query the state of a GPIO pin (even via extenders), so you can theoretically do without the switch plugins. But it will get complicated very fast.

I think the least complex solution is to use the Domoticz helper as described in the documentation But I do get it when you run out of possible tasks. You can skip the "button" switch task as it can also be achieved via GPIO monitoring in the rules (without the debounce option) And we can extend the Domoticz helper plugin to allow for a larger set of actuators + IDX.

I did just check the Domoticz MQTT helper code + how it is linked in the Domoticz MQTT controller. The plugin is using the Settings.TaskDeviceID which only allows for a single IDX value for a controller per task. (which is how it is intended to be used) It is essentially a very trimmed down version of a switch plugin, but then one without the option to have a successful call to PLUGIN_READ and thus never send back data to a controller. This means that creating a work-around to increase the number of possible actuators + IDX couples in the Domoticz MQTT helper will make a bigger mess. So that's not really an option I guess.

The Domoticz MQTT controller does translate the incomming MQTT messages to an internal command like "gpio,," or an equivalent PWM command, when it detects a "MQTT helper" task. So I wonder why it can't be doing the same on a "Switch" task like the "relay" task described in the documentation I linked before. Maybe it is just a matter of adding a flag to the switch plugin to explicitly mark it an "output only" or "input only" that will make this possible. Perhaps @giig1967g can say something about this?

What's holding me back quite a bit here is that it is potentially a very messy version of Pandora's box that we may be opening here when messing around in this code. So if it can be solved with the existing options then I would prefer it a lot as I really would like to move to a release version of ESPEasy and opening this GPIO/switch stuff is a guarantee for a lot of issues in the next weeks/months.

giig1967g commented 3 years ago

Hi @TD-er the idea of defining a switch task output or input only is good, but it will break existing configurations immediately (what would be the task setting after the upgrade? input or output?) So the only way to differentiate the input / output switches is to create two new plugins, one for input and one for output and mark as deprecated the current plugin.

Regarding DOMOTICZ behaviour, I do not have Domoticz in my setup, I use openHAB, so I can't exactly understand the issue, nor can replicate it. In order to help, I need more information.

megamarco833 commented 3 years ago

There are several ways we can approach this.

* Use Switch plugins for button and/or relay

* Act on GPIO from rules.

To first clearify the latter, as that option was not yet mentioned. You can call GPIO command to set a GPIO pin (even via GPIO extenders), and you can also enable "monitor" on a pin (even via GPIO extenders) to get an event when a pin state has changed. In rules you can also query the state of a GPIO pin (even via extenders), so you can theoretically do without the switch plugins. But it will get complicated very fast.

hi @TD-er and thanks again to spend time on this! i get a try to use rules to menage the switchlight but is not sufficient...

let me show a scenario that with lights can for sure happen: nodemcu_ESP(A) with these tasks: relay(a) and pushbutton(a) to trigger relay(a) nodemcu_ESP(B) with this task: relay(b) nodemcu_ESP(C) with this task: pushbutton(b) to trigger relay(b) and pushbutton(c) to trigger relay(a)

start with the simple case: nodemcu_ESP(A) only i have in domoticz idx=96=relay(a) and idx=97=relay(b) on espeasy i have: task1=kitchen_relay(a) on GPIO-13 (inverted relay so need to setup Switch input plugin) task2=wall_kitchen_1 pushbutton(a) on GPIO-5 (again switch input plugin) task3=wall_kitchen_2 pushbutton(b) on GPIO-4 (again switch input plugin)

first issue: command issue by domoticz => expected result espeasy receive the status change, update relay status accordingly to command received

domoticz send only messages like this: topic: domoticz/out

message OFF: { "Battery" : 255, "LevelNames" : "Off|Level1|Level2|Level3", "RSSI" : 12, "SelectorStyle" : "0", "description" : "", "dtype" : "Light/Switch", "hwid" : "6", "id" : "000140B0", "idx" : 96, "name" : "kitchen", "nvalue" : 0, "stype" : "Selector Switch", "svalue1" : "0", "switchType" : "On/Off", "unit" : 1 }

message ON: { "Battery" : 255, "LevelNames" : "Off|Level1|Level2|Level3", "RSSI" : 12, "SelectorStyle" : "0", "description" : "", "dtype" : "Light/Switch", "hwid" : "6", "id" : "000140B0", "idx" : 96, "name" : "kitchen", "nvalue" : 1, "stype" : "Selector Switch", "svalue1" : "0", "switchType" : "On/Off", "unit" : 1 } where we have information "idx number" and nvalue (1 or 0) to trigger accordingly the relay.

how to setup a rule without plugin domoticz helper? (also using monitor of GPIO for example) if possible i would like to avoid using mqtt helper for every relay, because it will "consume" for every relay a task...and we have 8 tasks.

second issue: command issued by pushbutton from espeasy -> expected result: triggere relay and update domoticz status how to setup a rule to send to trigger the relay accordingly and send to domoticz the status change of the relay?

of course in both "issue" i would like that domoticz know the status of the relay and it's pair with that.

The Domoticz MQTT controller does translate the incomming MQTT messages to an internal command like "gpio,," or an equivalent PWM command, when it detects a "MQTT helper" task. So I wonder why it can't be doing the same on a "Switch" task like the "relay" task described in the documentation I linked before.

yes, i hope so....it will avoid to use the helper plugin and save some tasks

Maybe it is just a matter of adding a flag to the switch plugin to explicitly mark it an "output only" or "input only" that will make this possible. Perhaps @giig1967g can say something about this?

What's holding me back quite a bit here is that it is potentially a very messy version of Pandora's box that we may be opening here when messing around in this code. So if it can be solved with the existing options then I would prefer it a lot as I really would like to move to a release version of ESPEasy and opening this GPIO/switch stuff is a guarantee for a lot of issues in the next weeks/months.

ok, i understand this. i would like just to find out how to menage wall pushbuttons, light relays assembled on nodemcu with firmware espeasy + domoticz + mqtt

thanks again for help !

megamarco833 commented 3 years ago

Hi @TD-er the idea of defining a switch task output or input only is good, but it will break existing configurations immediately (what would be the task setting after the upgrade? input or output?) So the only way to differentiate the input / output switches is to create two new plugins, one for input and one for output and mark as deprecated the current plugin.

Regarding DOMOTICZ behaviour, I do not have Domoticz in my setup, I use openHAB, so I can't exactly understand the issue, nor can replicate it. In order to help, I need more information.

hi @giig1967g first of all thanks so much for you help and attention for this issue! i try to explain in the message sent some minute ago how works domoticz, what kind of mqtt message it send out for ON or OFF with topic where these messages are been published.

I propose also a sort of "example scenario" to think about different location of nodemcu with espeasy firmware that can have: relay+pushbutton or only relay or only pushbutton and how to create something that can "connect&talk" using mqtt domoticz and espeasy with such as devices.

sorry if i wasn't and i'm not so clear but, please if you need something different let ask and i will try to do my best to try to explain it better.

TD-er commented 3 years ago

I wonder if the main problem with Domoticz may be that it starts to 'flipflop' only if the state in Domoticz is the inverse of the relay/gpio state. What the helper does, is it will send a direct state change using the GPIO command and the "switch" task connected to that pin will then update the state in Domoticz.

So why doesn't it work when the Domoticz MQTT controller is acting on the presence of a switch task to do the same as the helper task? The only reason I can think of is that it may have something to do with handling an inverse state. So if we just take into account the inverse state if it is set in the switch task, then I don't see why it will not work.

Maybe the need for the MQTT helper is in the end no longer needed since we can now schedule commands and events and have the gpio command no longer being handled in the switch plugin, but then only the inverse pin state should be dealt with.

sorry if i was and i'm not so clear but, please if you need something different let ask and i will try to do my best to try to explain it better.

If I'm not mistaken, you both have the same Italian background :)

tonhuisman commented 3 years ago

For Domoticz + MQTT + switch, please check the extensive example for it in the documentation Without the "Domoticz MQTT helper" plugin, it is next to impossible to get it right.

hi, that's fine, a configuration like this works with new firmware, but NOT with inverted relay ;(

I propose also a sort of "example scenario" to think about different location of nodemcu with espeasy firmware that can have: relay+pushbutton or only relay or only pushbutton and how to create something that can "connect&talk" using mqtt domoticz and espeasy with such as devices.

I think that the documentation TD-er linked to is just what you are talking about here, except, as you have found out the hard way, it is not really applicable for 'inverted' relays, as a) Domoticz MQTT Helper doesn't support inverting a 0/1 received value, and b) plugins don't have a way to send their state inverted to a Controller (and that inversion would only be applicable to 0/1 states, nothing else, AFAICS)

megamarco833 commented 3 years ago

I wonder if the main problem with Domoticz may be that it starts to 'flipflop' only if the state in Domoticz is the inverse of the relay/gpio state. What the helper does, is it will send a direct state change using the GPIO command and the "switch" task connected to that pin will then update the state in Domoticz.

yes, it could be... just for info, using tasmota for example it not happend. in tasmota you can select relay as inverted (realy_i) and you have just to write inside tasmota the idx of domotic coupled to the relay and nothing more. i tested and it works. also with pushbutton, you just create a rule: when pushbutton is trigger send mqtt message to tasmota device to trigger relay, and automatically domoticz it's updated. maybe we can do something similar :-)

So why doesn't it work when the Domoticz MQTT controller is acting on the presence of a switch task to do the same as the helper task? The only reason I can think of is that it may have something to do with handling an inverse state. So if we just take into account the inverse state if it is set in the switch task, then I don't see why it will not work.

yes, we could try to implement inverse option ?

Maybe the need for the MQTT helper is in the end no longer needed since we can now schedule commands and events and have the gpio command no longer being handled in the switch plugin, but then only the inverse pin state should be dealt with.

ok, but again i not understand how. lets continue to my example i report here my tests, logs and my configuration accordingly to easily part of my example: relay and pushbutton on same esp:

On System#Boot do    //When the ESP boots, do relay to OFF just to be sure
  gpio,13,1 //kitchen
  gpio,14,1 //bathroom
endon

on wall_kitchen_1#Switch do
  if [kitchen_rele#Switch]=0
    gpio,13,1
  else
    gpio,13,0
  endif
endon

i did two tests: 1) with enable inverted relay on kitchen_rele task (relay task)

20681309: EVENT: wall_kitchen_1#Switch=0
20681393: ACT : gpio,13,1
20681395: GPIO : port#13: set to 1
20684758: SW : GPIO=5 State=0 Output value=1
20684771: EVENT: wall_kitchen_1#Switch=1
20684858: ACT : gpio,13,1
20684859: GPIO : port#13: set to 1
20686762: SW : GPIO=5 State=0 Output value=0
20686773: EVENT: wall_kitchen_1#Switch=0
20686856: ACT : gpio,13,1
20686858: GPIO : port#13: set to 1
20688058: SW : GPIO=5 State=0 Output value=1
20688065: EVENT: wall_kitchen_1#Switch=1
20688147: ACT : gpio,13,1
20688149: GPIO : port#13: set to 1
20690258: SW : GPIO=5 State=0 Output value=0
20690265: EVENT: wall_kitchen_1#Switch=0
20690349: ACT : gpio,13,1
20690351: GPIO : port#13: set to 1

using the pushbutton, the relay never change the status

now i will use domoticz to trigger relay and not pushbuttons. start with domoticz device off, i click first time to make it on:

21020624: inputswitchstate is deprecatedinputSwitchState,1,1.00
21020632: GPIO : port#13: set to 1
21020662: SW : GPIO=13 State=1 Output value=0
21020677: EVENT: kitchen_rele#Switch=1
21020787: EVENT: kitchen#Output=1
21020911: EVENT: kitchen_rele#Switch=0

relay is off and domoticz still off

click second time on domoticz (that still off).

21099578: inputswitchstate is deprecatedinputSwitchState,1,1.00
21099584: GPIO : port#13: set to 1
21099646: EVENT: kitchen_rele#Switch=0
21099753: EVENT: kitchen#Output=1

relay is off and domoticz is now on

click third time on domoticz (that now is on, but relay is off).

21177595: inputswitchstate is deprecatedinputSwitchState,1,0.00
21177602: GPIO : port#13: set to 0
21177654: SW : GPIO=13 State=0 Output value=1
21177667: EVENT: kitchen_rele#Switch=0
21177779: EVENT: kitchen#Output=0
21177897: EVENT: kitchen_rele#Switch=1

relay is on now, and also domotic still on

click 4th time on domoticz (that is on and now also relay is on)

21262310: inputswitchstate is deprecatedinputSwitchState,1,0.00
21262317: GPIO : port#13: set to 0
21262341: EVENT: kitchen_rele#Switch=1
21262471: EVENT: kitchen#Output=0

relay is still on and also now domotic is off

click 5th time on domoticz (that is off and relay is still on)

21351813: inputswitchstate is deprecatedinputSwitchState,1,1.00
21351818: GPIO : port#13: set to 1
21351844: SW : GPIO=13 State=1 Output value=0
21351858: EVENT: kitchen_rele#Switch=1
21351968: EVENT: kitchen#Output=1
21352081: EVENT: kitchen_rele#Switch=0

relay is now off and also domotic is still off

here a log complete

21642937: inputswitchstate is deprecatedinputSwitchState,1,1.00
21642943: GPIO : port#13: set to 1
21643022: EVENT: kitchen_rele#Switch=0
21643126: EVENT: kitchen#Output=1
21645670: inputswitchstate is deprecatedinputSwitchState,1,0.00
21645675: GPIO : port#13: set to 0
21645715: SW : GPIO=13 State=0 Output value=1
21645731: EVENT: kitchen_rele#Switch=0
21645848: EVENT: kitchen#Output=0
21645959: EVENT: kitchen_rele#Switch=1
21650773: EVENT: Clock#Time=Sat,00:51
21652642: inputswitchstate is deprecatedinputSwitchState,1,0.00
21652647: GPIO : port#13: set to 0
21652717: EVENT: kitchen_rele#Switch=1
21652833: EVENT: kitchen#Output=0
21658135: inputswitchstate is deprecatedinputSwitchState,1,1.00
21658141: GPIO : port#13: set to 1
21658220: SW : GPIO=13 State=1 Output value=0
21658234: EVENT: kitchen_rele#Switch=1
21658343: EVENT: kitchen#Output=1
21658482: EVENT: kitchen_rele#Switch=0
21662874: inputswitchstate is deprecatedinputSwitchState,1,1.00
21662879: GPIO : port#13: set to 1
21662916: EVENT: kitchen_rele#Switch=0
21663018: EVENT: kitchen#Output=1
21666641: inputswitchstate is deprecatedinputSwitchState,1,0.00
21666647: GPIO : port#13: set to 0
21666714: SW : GPIO=13 State=0 Output value=1
21666729: EVENT: kitchen_rele#Switch=0
21666849: EVENT: kitchen#Output=0
21666963: EVENT: kitchen_rele#Switch=1
21670881: inputswitchstate is deprecatedinputSwitchState,1,0.00
21670886: GPIO : port#13: set to 0
21670923: EVENT: kitchen_rele#Switch=1
21671030: EVENT: kitchen#Output=0
21671337: DS : Temperature: 24.19 (28-69-c8-48-07-00-00-d1 [DS18B20])
21671349: EVENT: ds1#Temperature=24.19
21671479: DS : Temperature: 24.13 (28-2c-23-49-07-00-00-6a [DS18B20])
21671491: EVENT: ds2#Temperature=24.13
21673881: inputswitchstate is deprecatedinputSwitchState,1,1.00
21673886: GPIO : port#13: set to 1
21673919: SW : GPIO=13 State=1 Output value=0
21673933: EVENT: kitchen_rele#Switch=1
21674044: EVENT: kitchen#Output=1
21674153: EVENT: kitchen_rele#Switch=0

2) the second test is done with deselecting inverted option on relay task. now the behavior is correct, at every push button pressing conrespond a relay change status. of course in this case the information show in domoticz about relay status is the opposite on what we have in reality on relay side.

20823436: EVENT: wall_kitchen_1#Switch=1
20823526: ACT : gpio,13,0
20823528: GPIO : port#13: set to 0
20823562: SW : GPIO=13 State=0 Output value=0
20823576: EVENT: kitchen_rele#Switch=0
20825521: SW : GPIO=5 State=0 Output value=0
20825532: EVENT: wall_kitchen_1#Switch=0
20825617: ACT : gpio,13,1
20825619: GPIO : port#13: set to 1
20825662: SW : GPIO=13 State=1 Output value=1
20825678: EVENT: kitchen_rele#Switch=1
20827120: SW : GPIO=5 State=0 Output value=1
20827132: EVENT: wall_kitchen_1#Switch=1
20827221: ACT : gpio,13,0
20827223: GPIO : port#13: set to 0
20827252: SW : GPIO=13 State=0 Output value=0
20827266: EVENT: kitchen_rele#Switch=0
20829224: SW : GPIO=5 State=0 Output value=0
20829235: EVENT: wall_kitchen_1#Switch=0
20829324: ACT : gpio,13,1
20829326: GPIO : port#13: set to 1
20829367: SW : GPIO=13 State=1 Output value=1
20829381: EVENT: kitchen_rele#Switch=1

using the pushbutton, the relay correctly change the status for every trigger

starting from domoticz, every click on domoticz device correctly correspond on a relay triggering and change status. of course in this case if domoticz show relay on, in reality the relay is off and vice-versa.

Maybe the need for the MQTT helper is in the end no longer needed since we can now schedule commands and events and have the gpio command no longer being handled in the switch plugin, but then only the inverse pin state should be dealt with.

hope that my logs and test could help you on have ideas :) if we can avoid to use MQTT helper plugin is much better, we can save one task for every relay, and not have double tasks.

sorry if i was and i'm not so clear but, please if you need something different let ask and i will try to do my best to try to explain it better.

If I'm not mistaken, you both have the same Italian background :)

how you discovered that i'm Italian? :) :) :)

hestiap commented 3 years ago

Hi sorry to interfere in the discussion... I opened a topic on the forum esp switch+relay <-> domoticz no stop! and was told the discussion was here... My purpose is similar but not the same. I have switches and want to get data from domoticz with mqtt without interfere with those switches. In my testing when I send data to the Generic - MQTT Import (for instance duration for something else than the switches), there is an event on the switches and so I have changes I don't want. I understood it is normal... So what could be the good practice for this purpose? The Output - Domoticz MQTT Helper was not an help for me ;-)

hestiap commented 3 years ago

Hi sorry to interfere in the discussion... I opened a topic on the forum esp switch+relay <-> domoticz no stop! and was told the discussion was here... My purpose is similar but not the same. I have switches and want to get data from domoticz with mqtt without interfere with those switches. In my testing when I send data to the Generic - MQTT Import (for instance duration for something else than the switches), there is an event on the switches and so I have changes I don't want. I understood it is normal... So what could be the good practice for this purpose? The Output - Domoticz MQTT Helper was not an help for me ;-)

hestiap commented 3 years ago

Hi again I did it with an "asynevent" domoticz: http://esptest/control?cmd=asyncevent,DzTimeSec1=90 esp: on DzTimeSec1 do instead of "Generic - MQTT Import"

tonhuisman commented 3 years ago

@hestiap let's continue this on the forum, please provide all Rules (from all rules files) and current details for all devices/tasks and controllers in the thread you already posted in.

megamarco833 commented 3 years ago

For Domoticz + MQTT + switch, please check the extensive example for it in the documentation Without the "Domoticz MQTT helper" plugin, it is next to impossible to get it right.

hi, that's fine, a configuration like this works with new firmware, but NOT with inverted relay ;(

hi again, i find a solution that works with pushbuttons. i create this simple rule:

//Rules for pushbutton and relay on same ESP
on wall_kitchen_1#Switch do
  gpio,13,[kitchen_rele#Switch] // Invert relay state
endon

in this way i link the pushbutton to relay every single press of my push button change the status of the relay, so it's ok! with this rule, also domoticz is correctly showing and rapresenting the relay status.

the only issue is when the commands start from domoticz. i activate on espeasy the mqtt controller, but i guess that @TD-er got the point:

I wonder if the main problem with Domoticz may be that it starts to 'flipflop' only if the state in Domoticz is the inverse of the relay/gpio state. What the helper does, is it will send a direct state change using the GPIO command and the "switch" task connected to that pin will then update the state in Domoticz. So why doesn't it work when the Domoticz MQTT controller is acting on the presence of a switch task to do the same as the helper task? The only reason I can think of is that it may have something to do with handling an inverse state. So if we just take into account the inverse state if it is set in the switch task, then I don't see why it will not work. Maybe the need for the MQTT helper is in the end no longer needed since we can now schedule commands and events and have the gpio command no longer being handled in the switch plugin, but then only the inverse pin state should be dealt with.

could be someone start with this implementation that i can test? THANKS!

last point: how i can setup a rule that when i press my pushbutton it activate a relay that is connected to another esp? should be trough domoticz i guess, but before we should fix the mqtt comunication from domoticz->espeasy like the @TD-er proposal above...

anyway it's correct a rule like this?

//Rules for pushbutton on ESP(a) and relay on another ESP(b)
on wall_kitchen_1#Switch do  //pushbutton on ESP(a)
  Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "Toggle" }' // send to domoticz that will trigger relay on ESP(b)
endon

of course right now it now forks due a flick-flock domoticz<->espeasy thanks again

megamarco833 commented 3 years ago

I wonder if the main problem with Domoticz may be that it starts to 'flipflop' only if the state in Domoticz is the inverse of the relay/gpio state. What the helper does, is it will send a direct state change using the GPIO command and the "switch" task connected to that pin will then update the state in Domoticz.

So why doesn't it work when the Domoticz MQTT controller is acting on the presence of a switch task to do the same as the helper task? The only reason I can think of is that it may have something to do with handling an inverse state. So if we just take into account the inverse state if it is set in the switch task, then I don't see why it will not work.

Maybe the need for the MQTT helper is in the end no longer needed since we can now schedule commands and events and have the gpio command no longer being handled in the switch plugin, but then only the inverse pin state should be dealt with.

sorry if i was and i'm not so clear but, please if you need something different let ask and i will try to do my best to try to explain it better.

If I'm not mistaken, you both have the same Italian background :)

hi @TD-er , i warm up a bit the topic :) did you get the chance to red my last message? what do you think?

megamarco833 commented 3 years ago

@TD-er do you have some news to avoid this bug ?

thanks :)

TD-er commented 3 years ago

Sorry forgot to reply to it... The problem is that the "state" of the relay may not be the same as the intended state. For example a toggle relay does not have a single 1-to-1 relation to the "state".

What may be the intended state depends on 'where' you look. For example if you look from "Domoticz" then the state depends on what is set in Domoticz. The relay state should be updated in Domoticz as soon as it changes, but should Domoticz then "update" the state in Domoticz, or "correct" it? If you add a button in ESPEasy, then you will complicate things a lot. First intuition is probably to use rules to connect the button and the relay, so it also works when Domoticz cannot be reached and also it has the lowest latency. But what is the "truth" then? Is the state of the relay the truth? Should Domoticz update the state in Domoticz, or try to correct it?

One way to always keep states in sync is by managing the state in one place. But should it be in Domoticz? Or in ESPEasy? I don't think there is a single "correct" answer to that question as it depends.

How it is described in the documentation of the Domiticz helper is the most likely use case.

megamarco833 commented 3 years ago

ciao @TD-er ok, this is clear to me....but the issue is that domoticz helper not menage the inverted relay! so in this case it create a mess.

in particular i'm referring to your statement that you wrote some months ago:

I wonder if the main problem with Domoticz may be that it starts to 'flipflop' only if the state in Domoticz is the inverse of the relay/gpio state. What the helper does, is it will send a direct state change using the GPIO command and the "switch" task connected to that pin will then update the state in Domoticz.

So why doesn't it work when the Domoticz MQTT controller is acting on the presence of a switch task to do the same as the helper task? The only reason I can think of is that it may have something to do with handling an inverse state. So if we just take into account the inverse state if it is set in the switch task, then I don't see why it will not work.

Maybe the need for the MQTT helper is in the end no longer needed since we can now schedule commands and events and have the gpio command no longer being handled in the switch plugin, but then only the inverse pin state should be dealt with.

megamarco833 commented 3 years ago

ciao @TD-er sorry for stressing you... :-( did you get the chance to read my last post ? what do you think about inverse logic relay that actually are not possible to use with domoticz helper plugin? thanks!

TD-er commented 3 years ago

Sorry, have been really busy with other aspects, haven't thought of it the last week to be honest.

I guess (I think we mentioned it before) the MQTT helper should have this enabled (and the other code checked/adapted for it):

        Device[deviceCount].InverseLogicOption = false;

This way we invert it, similar to what the switch plugin allows to do. But have to look into it a bit more to be certain and right now I am digging deep in the WiFi issues a number of users reported the last week.

megamarco833 commented 3 years ago

ciao and thanks for the answer! no problem i can image that you are busy with other task, no hurry here :) related to: Device[deviceCount].InverseLogicOption = false; not sure to understand properly the comment, actually inside helper there isn't the option for inverse: immagine

but let take your time and then we can discuss.

in the meantime i tested setting on a device switch task on espeasy the relay inverted, than set the domoticz helper with idx of domnoticz, but still present the issue of "flipflop" from domoticz <=> espeasy (i mean continue activation and deactivation every second of connected relay)

TD-er commented 3 years ago

You have implemented it as described in the documentation of the helper?

megamarco833 commented 3 years ago

yes, i did it following the example. now i get it working but to obtain it working i changed the rule. here the configuration like the example: immagine immagine

here the rules to make it working:

on wall_kitchen_1#Switch do
  gpio,13,[kitchen_rele#Switch] // Invert relay state
  //gpio,13,=![kitchen_rele#Switch] // relay state
endon

what do you think? in this way i avoid the "flipflop" and the relay is working in both directions: command issue from domoticz or command issue triggering pushbutton from espeasy

now last point that i not succeed to solve: how to configure esp_A with push button to trigger relay on esp_B esp_B with relay domoticz idx = 97

how to setup the system and the rule?

TD-er commented 3 years ago

You can also use events and ESPEasy p2p to send an event to the other unit. In the rules you can react on the event. Just make sure to set each node to use a unique unit ID (not 0, not 255) See ESPEasy p2p documentation And the Sendto command documentation

megamarco833 commented 3 years ago

i already did like this on esp_B where i have only the push button:

on swith_kitchen_3#Switch do
  sendTo nodemcu_153_153,"GPIO,13,1"1 // Invert relay state
endon

it seams that looking at the log the command is ok:

25628131: SW : GPIO=12 State=0 Output value=0
25628143: EVENT: swith_kitchen_3#Switch=0
25628153: ACT : sendTo nodemcu_153_153,'GPIO,13,1'1

but the GPIO 13 on ESP_A never change the status

looking at ESP_A name i see: immagine

and inside rule i use: nodemcu_153_153 becuse looking at controlled web page inside espeasy GUI, where i set domoticz as controller, i see:

immagine

so what i'm doing wrong?

uzi18 commented 3 years ago

Look at log in esp_A if cmd is received and executed, check if p2p port is same and switch task definied for gpio13 on esp_A

tonhuisman commented 3 years ago

AFAIK, the unit number should be used in the SendTo command, like SendTo,153,"GPIO,13,1", but not/never the MQTT name (nor the unit name, though I did have plans to change that some time ago, still on the todo list), as SendTo has nothing to do with MQTT. Be aware that SendTo uses UDP transport, meaning it is 'fire and forget', so no confirmation of being received is returned. If you need that kind of confirmation, SendToHTTP should better be used (with a somewhat different syntax).

TD-er commented 3 years ago

Also maybe it is better to not send the GPIO command to the other node, but rather send an event which is then handled on the receiving node in the rules. Then you only need to focus on that node while debugging instead of keeping track of several nodes where you may need to keep state of the pin.

In short:

megamarco833 commented 3 years ago

Also maybe it is better to not send the GPIO command to the other node, but rather send an event which is then handled on the receiving node in the rules. Then you only need to focus on that node while debugging instead of keeping track of several nodes where you may need to keep state of the pin.

In short:

* Send only the event to trigger the intended action to the other node

* On the receiving node, process the event just like you process pressing a button on that node. (the node with the relay is able to check the state of the relay, the remote node isn't)

* Use Unit NR to address the other node, not a node name.

* Double check the UDP port nr in Tools => Advanced.

ok, let proceed by steps :)

1) the issue was referring to name of ESP, correct was referring to number of ESP (thanks @tonhuisman) looking at the log of ESP_A now i can see the GPIO triggering (tanks @uzi18 for suggest) anyway now the status change.

but two question: 1) how to manage toggle? (i'm still with GPIO directly control) 2) how to link pushbutton status on ESP_B to status of relay on ESP_A?

on ESP_A (number 153) i have:

on wall_kitchen_1#Switch do
  gpio,13,[kitchen_rele#Switch] // Invert relay state
//gpio,13,=![kitchen_rele#Switch] // this is for relay NOT inverted
endon

thanks to this rule when push button wall_kitchen_1 set as active low change it's status gpio13 (relay) take the opposite value (i have inverted relay)

on ESP_B (number 152) i have:

on switch_kitchen_3#Switch do
  if [switch_kitchen_3#Switch]=0
    sendTo,153,"GPIO,13,1" // Invert relay state
  else
    sendTo,153,"GPIO,13,0"
  endif
endon

consider this case that i test: first i push the button named as switch_kitchen_3 => the relay on esp_A correctly trigger to ON and domoticz correctly show the relay as ON (idx=96) now i click on domoticz to turn OFF relay => it works, relay is phisically set to OFF in espeasy ESP_A now i push the button on ESP_B => but in this case the relay on ESP_A stay off, i have to click twice on push button to turn relay on. this is because push button is not linked to status of relay.

i have another concern....should domoticz be the "brain" of the system, so i try to change rule on ESP_B push button like this:

on switch_kitchen_3#Switch do
Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "Toggle" }'
endon

it change the status of relay on domoticz....but why in this case relay on ESP_A is not change physically the status???

if i click by myself on domoticz i see on log ESP_A (esp with relay) 1279322: inputswitchstate is deprecatedinputSwitchState,0,0.00 1279336: inputswitchstate is deprecatedinputSwitchState,1,0.00 1279343: GPIO : port#13: set to 0 1279390: EVENT: wall_kitchen_1#Switch=1 1279502: ACT : gpio,13,1 1279505: GPIO : port#13: set to 1 1279546: SW : GPIO=13 State=1 Output value=0 1279565: EVENT: kitchen_rele#Switch=1 1279711: EVENT: kit_idx96#Output=0 1279867: EVENT: kitchen_rele#Switch=0

if i use: Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "Toggle" }' domoticz show a different relay status, so domoticz receive the commands properly, but inside logs of ESP_A there is nothing and relay on ESP_A phisically never change the status.

to have push button linked to domoticz i also try: instead of Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "Toggle" }' i try Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "[switch_kitchen_3#Switch]" }' but it now work, domoticz log: 2021-05-20 11:31:40.314 Error: MQTT client: MQTT: Error sending switch command! is it possible publish a string that contain a dynamic value of pushbutton status?

TD-er commented 3 years ago

You can also use the command gpiotoggle. But this is exactly why I suggested to send an event via p2p and let the pin state change be handled on the receiving node with the relay.

This is very much the same as how events are being handled in the described Domoticz MQTT helper plugin There is described how to act on the event sent by the push button, but the same can be done when sending an event from another node.

So you just have to think of some event name like "remoteToggle" or whatever makes sense and just send that event from the remote node. On the receiving node you make a section in the rules to handle that event.

The event flow is also described in the domoticz MQTT helper documentation. Just keep in mind, any actor that needs to set the relay should perform the same as when you press a button on the node with the relay. The helper will then keep Domoticz state in sync with the relay state.

megamarco833 commented 3 years ago

ok, but on esp_A where i have push button and relay and helper plugin, i can link the status of push button with relay (like in the example)

on wall_kitchen_1#Switch do
  if [kitchen_rele#Switch]=0
    gpio,13,0
  else
    gpio,13,1
  endif
endon

but on esp_B where i have only task with push button (no helper here, correct?) how i can link the pushbutton to relay in another usb? i can only control the GPIO toggle, like:

on switch_kitchen_3#Switch do
  sendTo,153,"gpiotoggle,13"  //toggle command
endon

what i'm missing?

TD-er commented 3 years ago

Basically what you need to do there is something (exactly?) like this:

on switch_kitchen_3#Switch do
  sendTo,153,"event,wall_kitchen_1#Switch"  //Act like the switch is pressed on other node
endon
megamarco833 commented 3 years ago

yes, correct! thank @TD-er i not think about it, sorry ;( i tested and it works!

but why if i use:

on switch_kitchen_3#Switch do
Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "Toggle" }'
endon

it send to domoticz the status change of idx96 and domoticz change it...BUT why espeasy phisically not change the status of relay?

separate question: can i use the publish command to send a string but whit inside a dynamic value inside? if for example i would like to send to domoticz the value of switch_kitchen_3#Switch ? i test: Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "switch_kitchen_3#Switch" }' but not works...it send a string = switch_kitchen_3#Switch i want that it send 0 or 1 is it possible with espeasy? thanks

TD-er commented 3 years ago
Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "[switch_kitchen_3#Switch]" }'

You have to address a task value using the [taskname#taskvarname] syntax, thus with square brackets.

See also formatting documentation to transform a 0 or 1 into ON or OFF.

Why Domoticz doesn't update it, but ESPEasy doesn't, I don't know. If I flip a switch in Domoticz, my relay on a Sonoff switches along with it. ESPEasy should be subscribed to that topic and see the message on the broker, so it should act on the IDX value if it is the same as set in the helper and/or the switch task.

I did look into the Domoticz code and I don't see the "Toggle" command. Are you sure ESPEasy does use that command to switch the state? ESPEasy only acts on "on" or "off", not on "toggle" as far as I can see.

megamarco833 commented 3 years ago

Why Domoticz doesn't update it, but ESPEasy doesn't, I don't know. If I flip a switch in Domoticz, my relay on a Sonoff switches along with it. ESPEasy should be subscribed to that topic and see the message on the broker, so it should act on the IDX value if it is the same as set in the helper and/or the switch task.

I did look into the Domoticz code and I don't see the "Toggle" command. Are you sure ESPEasy does use that command to switch the state? ESPEasy only acts on "on" or "off", not on "toggle" as far as I can see.

"toggle" is a domoticz command.

anyway i test also with "On" or "Off" please note that domoticz accept it only with capital letter at begin (it's mandatory) and looking at format table we have only OFF or ON not Off or On anyway, just for test i used inside espeasy tool -> send command and i used: Publish domoticz/in,'{"idx":96,"RSSI":7,"command":"switchlight","switchcmd":"On"}' or Publish domoticz/in,'{"idx":96,"RSSI":7,"command":"switchlight","switchcmd":"Off"}' it is did on ESP_B (esp with only pusb button) relay is on ESP_A (where i have the helper plugin and relay task)

in this case domoticz change and show the status of idx96 but espeasy not react and also looking at the log of espeasy i can not see nothing

TD-er commented 3 years ago

"toggle" is a domoticz command.

Could be, it isn't implemented in the Domoticz controller as far as I could see. The On Off difference can of course be implemented in the rules, but it does take a bit more space as you need to copy/paste the publish line and check the task value state.

Not 100% sure of why ESPEasy doesn't react on it, as it may have to do with slight differences in how the command is formatted, or maybe we're missing some simple thing like the IDX not matching on the MQTT helper. As you can see in the MQTT helper plugin documentation both the switch plugin acting on the relay and the MQTT helper must use the same IDX.

megamarco833 commented 3 years ago

immagine immagine

these are the two task for relay on ESP_A (153) where i have relay and helper tasks

on wall_kitchen_1#Switch do
  if [kitchen_rele#Switch]=0
    gpio,13,0
  else
    gpio,13,1
  endif
endon

here the rule for push button task on same ESP_A (153)

about esp_B (152) with only the push button task i have:

on switch_kitchen_3#Switch do
  sendTo,153,"event,wall_kitchen_1#Switch"  //Act like the switch is pressed on other node
endon

and ok, this is working

NOW if i want that domoticz is the "head" i use this rule:

on switch_kitchen_3#Switch do
if [switch_kitchen_3#Switch]=0
Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "On" }'
else
Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "Off" }'
endif
endon

this rule is working on domoticz side. when i trigger the push button switch_kitchen_3#Switch i can see that domoticz change the icon of idx96 accordingly. but when domoticz change the status (because recive the mqtt message from to the rule above of esp_B 152) espeasy on esp_A 153 not react. that's strange.... because if i click on domoticz icon (so command start from domoticz) esp_A react and change the relay status.

TD-er commented 3 years ago

Just a quick note, before I continue reading your post :)

on switch_kitchen_3#Switch do
 if [switch_kitchen_3#Switch]=0
  Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "On" }'
 else
  Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "Off" }'
 endif
endon

You are acting on switch_kitchen_3#Switch as event, so better not to try reading the switch state but rather use the %eventvalue1% :

on switch_kitchen_3#Switch do
 if %eventvalue1%=0
  Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "On" }'
 else
  Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "Off" }'
 endif
endon
megamarco833 commented 3 years ago

ok, thanks for realt time suggestion :)

in the mean time, i verify what domoticz receive as mqtt message:

 2021-05-21 12:12:18.026 Debug: MQTT client: MQTT: Topic: domoticz/in, Message: {"command": "switchlight", "idx": 96, "switchcmd": "On"}
2021-05-21 12:12:18.825 Debug: MQTT client: MQTT: Topic: domoticz/in, Message: {"command": "switchlight", "idx": 96, "switchcmd": "Off"} 

so domoticz receive properly the command and react in the correct way (i see icon of dummy switch idx96 that change to ON and then to OFF) but espeasy on ESP_A 153 not react triggering the relay accordingly to domoticz.

on the other side if i use domoticz, by clicking on dummy switch idx96, espeasy on ESP_A 153 react triggering the relay accordingly to domoticz.

megamarco833 commented 3 years ago

"toggle" is a domoticz command.

Could be, it isn't implemented in the Domoticz controller as far as I could see. The On Off difference can of course be implemented in the rules, but it does take a bit more space as you need to copy/paste the publish line and check the task value state.

https://www.domoticz.com/wiki/MQTT here you can see the "toggle"

Sending a Scene Command

{"command": "switchscene", "idx": 24, "switchcmd": "On" }
{"command": "switchscene", "idx": 24, "switchcmd": "Toggle" }

i tested also for switchlight and it works properly

about transforming On and Off not understand how to paste the espeasy valure 0 to On (inverted) coming from if [kitchen_rele#Switch]=0 and append to commando like this: Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "On"}

TD-er commented 3 years ago

about transforming On and Off not understand how to paste the espeasy valure 0 to On (inverted) coming from if [kitchen_rele#Switch]=0 and append to commando like this: Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "On"}

Just assuming you act on the event kitchen_rele#Switch

on kitchen_rele#Switch do
 if %eventvalue1%=0
  Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "On" }'
 else
  Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "Off" }'
 endif
endon

Just like above. But I guess we're now prone to mixing up things again.

Node A:

Node B:

Node A should connect the button to the relay as you already did according to the documentation. Important to note: The button task on Node A does not interact with Domoticz, does not have an IDX set, it ONLY sends an event which we'll process in the rules.

Node B should not try to send to the MQTT controller, but rather try to send an event to Node A as if it pushes a button. So regardless of where the physical button on Node A is pushed or on Node B, it should trigger the same event on Node A as that's known to work along with Domoticz and the relay.

So the rules on Node B should act on the button event and send an event to Node A. That's it.

Node A will process the same event, regardless of its origin (physical button on Node A, or event from Node B. This should trigger a number of actions:

Since that's already working on your setup when you press the button on Node A, I really don't get it why it doesn't work when triggering it on Node B. It should be the same event as triggered from pressing the button on Node A.

tonhuisman commented 3 years ago

This, though sub-optimal, rule:

on switch_kitchen_3#Switch do
 if [switch_kitchen_3#Switch]=0
  Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "On" }'
 else
  Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "Off" }'
 endif
endon

can actually be simplified using variable formatting and justification like this:

on switch_kitchen_3#Switch do
  let,96,%eventvalue1%
  Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "[var#96#O#C]" }'
endon

(Formatting O = OFF/ON, Justification C = Capitalize first character, implicitly lower-casing the rest of the word) We can't directly apply formatting and justification on %eventvalue%, but using an internal variable we can 😄 And by using !O instead of O for the formatting, the value can be inverted.

megamarco833 commented 3 years ago

about transforming On and Off not understand how to paste the espeasy valure 0 to On (inverted) coming from if [kitchen_rele#Switch]=0 and append to commando like this: Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "On"}

Just assuming you act on the event kitchen_rele#Switch

on kitchen_rele#Switch do
 if %eventvalue1%=0
  Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "On" }'
 else
  Publish domoticz/in,'{"command": "switchlight", "idx": 96, "switchcmd": "Off" }'
 endif
endon

Just like above. But I guess we're now prone to mixing up things again.

ok, lets try to make it a bit more clear :) the rule above is not necessary for node_A that has:

PLUS this rule that you suggest and that it is working:

on wall_kitchen_1#Switch do
  if [kitchen_rele#Switch]=0
    gpio,13,0
  else
    gpio,13,1
  endif
endon

nothing more on node_A

in this node_A is not needed rule with publish on domoticz/in.... (is not needed thanks to helper plugin and idx set on relay task)

Now I came to my request about publish to domoticz. I try to explain: my request about how to format "On" /"Off" to publish on domoticz was for node_B (not for node_A) where, in node_B, we have only the push button. So to be more precise, in case of node_B i don't want to trigger event wall_kitchen_1 like this:

on switch_kitchen_3#Switch do
  sendTo,153,"event,wall_kitchen_1#Switch"  //Act like the switch is pressed on other node
endon

but i want triggering directly domoticz with idx, and then domoticz should "talk" with esp node_A that should trigger the relay accordingly. and this second case is not working (if node_B publish domoticz/in) i'm asking why it's not working this part :-) because i tested it and it not works, and i was surprised about that.

again, if node_B trigger the event wall_kitchen_1 like with the rule above reported all works.

that's all from this part :) hope that now i explain better, sorry if i make confusion before !

Node A:

* button

* relay

Node B:

* button

Node A should connect the button to the relay as you already did according to the documentation. Important to note: The button task on Node A does not interact with Domoticz, does not have an IDX set, it ONLY sends an event which we'll process in the rules.

Node B should not try to send to the MQTT controller, but rather try to send an event to Node A as if it pushes a button. So regardless of where the physical button on Node A is pushed or on Node B, it should trigger the same event on Node A as that's known to work along with Domoticz and the relay.

So the rules on Node B should act on the button event and send an event to Node A. That's it.

Node A will process the same event, regardless of its origin (physical button on Node A, or event from Node B. This should trigger a number of actions:

* Toggle relay

* Update state on Domoticz

yes all correct and all well described! we are in the same page

Since that's already working on your setup when you press the button on Node A, I really don't get it why it doesn't work when triggering it on Node B. It should be the same event as triggered from pressing the button on Node A.

as i tried to explain above, no issue if node_B trigger event on node_A the issue is if node_B trigger domoticz (and it works) but we miss the next passage: relay on node_A should react after node_B triggered domoti cz, and this not happened


second issue that i find at reboot: if node_A reboot and the relay was Off at the moment of reboot. after reboot, the relay will be turned On.

maybe because of rule on node_A

on wall_kitchen_1#Switch do
  if [kitchen_rele#Switch]=0
    gpio,13,0
  else
    gpio,13,1
  endif
endon

maybe the GPIO of wall_kitchen_1 change the status at boot so espeasy trigger the relay.

second test: if node_A reboot and the relay was On at the moment of reboot. after reboot, the relay will be turned On. (so in this case the status of relay previous the boot was preserved)

how to avoid?