Control Relais via MQTT and Switch Input

[gf7kp]

Hello,

I have a Switch Input with an external switch connected which controls a relais
A Relais connected via Switch Input
and I want to control the relais via MQTT via ioBroker and the Switch Imput

Following configuration works, but it seems a little bit cumbersome to me.
And I have two MQTT values in ioBroker. One read only and a second for update. Is it possible to have one MQTT value for get and set?
Do you have an idea for a better implementation?

a.png (26.22 KiB) Viewed 9226 times

b.png (31.24 KiB) Viewed 9226 times

c.png (20.65 KiB) Viewed 9226 times

Rules:

On System#Boot do
Publish TESTMCU/Relais1/MQTT_Relais1,0 //send MQTT Update (to prevent, that wrong/old value from MQTT controller will be sent)
TaskValueSet 2,1,0 //Update MQTT value
gpio,14,1 //default switch value
endon


//--- trigger via VALUE
// Relais1_State = NOT Inversed, ON = 0
on Relais1#Relais1_State=1 do //1 = OFF
Publish TESTMCU/Relais1/MQTT_Relais1,0
TaskValueSet 2,1,0
endon
on Relais1#Relais1_State=0 do
Publish TESTMCU/Relais1/MQTT_Relais1,1
TaskValueSet 2,1,1
endon

//--- Änderung Werte über MQTT
on TESTMCU#MQTT_Relais1_Value=1 do
gpio,14,0
endon
on TESTMCU#MQTT_Relais1_Value=0 do
gpio,14,1
endon

Thank you!

[TD-er]

Your rules can be simpler.
See: https://espeasy.readthedocs.io/en/lates ... red-values
For example:

Code: Select all

on Relais1#Relais1_State do 
  //1 = OFF
  // !%eventvalue1% is invert the 1st eventvalue
  Publish TESTMCU/Relais1/MQTT_Relais1,!%eventvalue1%
  TaskValueSet 2,1,!%eventvalue1%
endon

And you can maybe also consider defining your own events. Maybe that's easier to manage as you then only need to change things on one side if things need to be changed.
Also you move the responsibility and device specific knowledge to the ESPEasy node instead of your domotica system.

First you need to look into your MQTT topic structure on how to enter commands to be sent to the ESPEasy node.
The command can then be like "event,MyEventName=1" and in the rules you act on it like "on MyEventName do ..."

[gf7kp]

Thanks!
I'll give it a try

But to be honest, I've hope to get something much more simple.
I have some devices with Tasmota and in ioBroker I have a state "Power" for a switch which is True or False. And I don't have to do anything. Just use it.
Maybe such a simple/easy solution will be available in a next version of ESP Easy
But it's really great for all my sensors connected to ESPs

[TD-er]

Well you are using the value, only you needed to 'flip' the value, which is done with the negation ("!")
And you're just acting on the event of the value update, not just on the update matching a specific value.

[iron]

Well you are using the value, only you needed to 'flip' the value, which is done with the negation ("!")
And you're just acting on the event of the value update, not just on the update matching a specific value.

I think he is implying that he is only using MQQT just to store the value which is not the case in tasmota... just saying

[gf7kp]

Well you are using the value, only you needed to 'flip' the value, which is done with the negation ("!")
And you're just acting on the event of the value update, not just on the update matching a specific value.

I think he is implying that he is only using MQQT just to store the value which is not the case in tasmota... just saying

What do you mean with "store the value"?
I'm not an expert in MQTT... all I want is to get the current status of my relais via MQTT and the possibility to switch the relais with the same MQTT value.

I don't have a screenshot of my example above. But as you can see in this example I have two values in my MQTT server from ESPEasy. One from the switch input device and one from MQTT which I can use to switch the relais via MQTT. But I have one for READ and one to SET.
Here an example of my MQTT server which is ioBroker.

e.png (11.87 KiB) Viewed 9132 times

With Tasmota it looks like this. Just to show you what I want to have also with ESPEasy.
I can use this value to see the current status and to switch it.
Is this also possible with ESPEasy? Or easier than my solution from my 1st post. Ideally without using rules? This would be easy and great
If not, than I will optimize my rules and use it that way

Thank you!

[iron]

It is an option in the ESPEasy MQTT controller setting to "Retain last value" so upon reconnection system will get the "last known status"

[localhorst]

More then 2 years later to the last post, I would like to ask if there is something new / changed to this topic:

But to be honest, I've hope to get something much more simple.
I have some devices with Tasmota and in ioBroker I have a state "Power" for a switch which is True or False. And I don't have to do anything. Just use it.
Maybe such a simple/easy solution will be available in a next version of ESP Easy
But it's really great for all my sensors connected to ESPs

all I want is to get the current status of my relais via MQTT and the possibility to switch the relais with the same MQTT value.

As I use ioBroker as well as my main system (and all scripts are running there), and I'm getting in the situation not to just read measured values from sensors, but have to actively switch DACs on a ESPEasy device, I soon have to program it - in ioBroker.

As far as I understand, now I'll have to fire a command via URL to the ESP, where the rules take care of it and switch the DAC. But this would not be really bidirectional, as I would have to check against the MQTT value myself, if the switch really has the new and correct state.
Or do I misunderstand something?

[TD-er]

You could also set a variable which you can check by sending a command to a specific topic and then via the rules publish the last set value to a specific topic.

See the documentation to send commands via MQTT to ESPEasy
https://espeasy.readthedocs.io/en/lates ... d-handling

[localhorst]

See the documentation to send commands via MQTT to ESPEasy
https://espeasy.readthedocs.io/en/lates ... d-handling

Thank you, that gave me some task!

I guess, I have it, like I need it to be.

Changing a value in ioBroker, e.g. VentSwitch_Schaltstufe_WZ-SZ:

ioBroker

Bildschirmfoto 2024-01-19 um 17.49.06.png (177.26 KiB) Viewed 2314 times

changes it in ESPEasy in MQTT Import (value 1) and reflects it to a device (Dummy1):

ESPEasy

Bildschirmfoto 2024-01-19 um 17.49.43.png (196.08 KiB) Viewed 2314 times

As the value in Dummy1 changes, ESPEasy sends the actual value back to ioBroker, as seen on the ioBroker Screenshot: VentSwitch_Schaltstufe_WZSZ_State

The rules for it:

Code: Select all

on MQTT_Import#Schaltstufe_WZSZ do 
  //Write internally into a different variable / device:
    TaskValueSet,2,1,%eventvalue1%
  // Publish back the state to ioBroker
      if [Dummy1#Dummy]=%eventvalue1%
        Publish, VentSwitch_Schaltstufe_WZSZ_State,%eventvalue1%
      endif   
endon

on MQTT_Import#Schaltstufe_Kinder do 
  //Write internally into a different variable / device:
    TaskValueSet,3,1,%eventvalue1%
  // Publish back the state to ioBroker    
      if [Dummy2#Dummy]=%eventvalue1%
        Publish, VentSwitch_Schaltstufe_Kinder_State,%eventvalue1%
      endif   
endon

Any suggestions to make it better or anything what could be a problem?

[TD-er]

Do you actually see the events being triggered in the (web/serial) logs?
If I'm not mistaken, there was some checkbox to send events on the received topics in MQTT import?

N.B. for commands like I linked in the docs, you don't need to use MQTT import.
You can just embed some commands either in the topic or in the message or combined. (see the docs page).
For example you can trigger some event via these commands.
Using events is probably a lot easier than sending a specific parameter of a command (e.g. gpio command where you want to have the pin as the message, but it isn't the last argument of that command)

When debugging rules, I often use the command "logentry" as it allows me to see what arguments are given and if an event is even triggered or handled in the rules.

You can use just about anything in the logentry command, as long as you keep the argument of the command wrapped in quotes.

Code: Select all

on MQTT_Import#Schaltstufe_WZSZ do 
  logentry,"Handling MQTT_Import#Schaltstufe_WZSZ: ev1: %eventvalue1% Dummy: [Dummy1#Dummy]"
  //Write internally into a different variable / device:
    TaskValueSet,2,1,%eventvalue1%
  // Publish back the state to ioBroker
      if [Dummy1#Dummy]=%eventvalue1%
        Publish, VentSwitch_Schaltstufe_WZSZ_State,%eventvalue1%
      endif   
endon

It can also be useful to use a tool like MQTT Explorer (available via Windows Store) or some other tool for other OS-es.
This way you can also subscribe to the same topics and see what has been sent.

[TD-er]

By the way, the if statement is probably always true, as you just set the value to the dummy in the line above.

[Ath]

And if you'd used the task and value name for the TaskValueSet command, that would have been more visible, and also portable to another unit

Code: Select all

  TaskValueSet,Dummy1,Dummy,%eventvalue1%

And you can also set the Dummy device to have 2, 3 or 4 values, but when sending each value separately to a controller that won't work, that's clear.

[localhorst]

Do you actually see the events being triggered in the (web/serial) logs?
If I'm not mistaken, there was some checkbox to send events on the received topics in MQTT import?

I haven't checked the logs.
I only change the steering variable in ioBroker, see how it immediately changes on the ESP and then can see that it's bounced back to ioBroker from the ESP into my *_state variable.
So, this is a proof that it works and ESP and ioBroker are talking to each other like intended.

N.B. for commands like I linked in the docs, you don't need to use MQTT import.
You can just embed some commands either in the topic or in the message or combined. (see the docs page).
For example you can trigger some event via these commands.
Using events is probably a lot easier than sending a specific parameter of a command (e.g. gpio command where you want to have the pin as the message, but it isn't the last argument of that command)

I have to admit that I'm not sure how this looks like. I'm afraid, I don't understand it yet. Would I send a URL call with the command to the ESP?

By the way, the if statement is probably always true, as you just set the value to the dummy in the line above.

Yes, that's true - if you think inside the ESP only. But...
This is a double check (or self build bidirectional action), that the changed value from ioBroker has arrived on the ESP (and the DAC) and being executed properly (and not went into the blue because of network trouble or whatever). If the value haven't been properly processed on the ESP, the *_state variable would remain on the old value in ioBroker. And I would see in my visualization that something is wrong, e.g. because the CO2 value is not fitting together with the ventilation setting. Please see "Aktuelle Einstellung" - which is (currently as well) taking a *_state variable, means is showing the actual state of the device, not the commanded state / value. I don't want to see what ioBroker have commanded, but what state the ESP is really executing:

IMG_2778.PNG (1.42 MiB) Viewed 2281 times

I hope it's more or less understandable, what I've written.

And you can also set the Dummy device to have 2, 3 or 4 values, but when sending each value separately to a controller that won't work, that's clear.

This is just for testing now. The dummy devices should be replaced by the DACs.

[TD-er]

Well Ton put in a lot of effort to also allow task names and taskvaluenames to be used in commands
And you can also have some plugin specific commands (e.g. to reset something, or put text on a display, etc) which can also be useful to send to a specific task.
So you can also prefix a plugin specific command with the task name followed by a dot (.) to address a specific task when you have multiple instances of the same plugin (e.g. multiple temperature sensor of the same type)

It makes the rules a lot more readable when using names instead of numbers.

And about the commands sending via MQTT...
It is literally described in the page I linked.
You can publish from somewhere a message to some topic (with cmd in the topic as described) and those ESPEasy nodes subscribed to such a topic will receive the command and try to execute it.
Of course you can't use any command as some are restricted commands. For example a factory reset isn't something you want to give from anywhere.

But you can trigger an event or asyncevent with a number of parameters you would like to use and then handle it from within the rules.
From the rules there are no restrictions on commands so if you really really want to call for a factory reset from within the rules, you are allowed to

[localhorst]

And about the commands sending via MQTT...
It is literally described in the page I linked.
You can publish from somewhere a message to some topic (with cmd in the topic as described) and those ESPEasy nodes subscribed to such a topic will receive the command and try to execute it.

I'm so sorry, but I think first you need to do it "ESPeasy for dummies" way for me stupid.
How is the way / how do I place the commands from ioBroker to the ESP?
Just like I switch off my displays, like:

Code: Select all

http://192.168.1.58/control?cmd=oledframedcmd,display,off

?

[TD-er]

OK, let's assume you have your Home Assistant/OpenHAB MQTT controller subscribed to anything starting with %sysname%/#
The # is the wildcard symbol for MQTT topics and %sysname% will be replaced by some string.
What this string is, you can easily see by running this from the tools page and either have a tab in your browser open on the log, or via serial log:

Code: Select all

logentry,"System name for MQTT topic: `%sysname%`"

The web log output:
691381406: HTTP: logentry,'System name for MQTT topic: `%sysname%`'
691381414: System name for MQTT topic: `ESP_Easy_s2_190`
[/code]

So this means the MQTT controller in ESPEasy will subscribe to anything starting with whatever your system replaces for %sysname%/

Now take a look at the page I linked before: https://espeasy.readthedocs.io/en/lates ... #c005-page

On my system, I can publish a message to a topic like this:

Code: Select all

ESP_Easy_s2_190/cmd

And the message can be something like this:

Code: Select all

asyncevent,MyEvent=123

Then in the rules:

Code: Select all

on MyEvent do
  logentry,"Event: MyEvent with eventvalue: %eventvalue1%"
endon

But since it can be more useful in some setups to just send a single integer as a message, you could send to this topic:

Code: Select all

ESP_Easy_s2_190/cmd_arg2/event/myevent

And just send the value as a message:

Code: Select all

123

N.B. "cmd_arg2" is used here as "myevent" is the first argument and "123" is the 2nd argument of the command "event"

This will be converted in the command:

Code: Select all

event,"myevent=123"

You can also do a bit more complex stuff like this:

Code: Select all

ESP_Easy_s2_190/cmd_arg2/oledframedcmd/display

And just send the action as a message:

Code: Select all

off

This will be converted in the command:

Code: Select all

oledframedcmd,display,off

Is this ESP-Easy enough?

[localhorst]

I've made a Screenvideo of how it currently works: https://breest.net/index.php/s/HaBNLgWzf5d7m6Y
This seems, from what I expected how the DACs could be controlled, pretty much perfect to me. I just program in ioBroker on the variables in ioBroker. And get a state back. Everything needs to come and go to ioBroker. The rules just sort it inside ESPEasy.
You are trying to show me a better way? Or there is something wrong with how I do it? I need to sort out tomorrow what I don't understand / what I am missing. Maybe I have totally basic misunderstanding, I don’t know at the moment, I’m sorry.
I’ll better go to bed for now.

[localhorst]

OK, I guess now I understand:

Bildschirmfoto 2024-01-20 um 17.39.01.png (427.64 KiB) Viewed 2091 times

I can directly shoot commands to an actuator, without the need of a rule on the ESP, fine.

But I think, that I'll rather go through the Generic - MQTT Import device with basically the rules I've created before, to get the state into ioBroker.
I assume that each DACs will need a single value for the desired voltage. So this will be only 3. And for my feeling the most convenient and clean way for me for programming later in ioBroker.