Espeasy: P029 MQTT helper does not log anymore

[wdonker]

In ESPEasy version v2.0-20180122 there is no logging of switching the GPIO. Until at least
v2.0-20180112 there was. The missing line is this one:
SW : GPIO 12 Set to ...

Maybe related to fixing issue #732

[TD-er]

OK, will have a look at it.
Can you also post some relevant screenshots of the configuration? (@Grovkillen has made some tool to automate creation of screenshots)

[Grovkillen]

https://github.com/Grovkillen/ESP_Easy_Webdumper

[wdonker]

Well, the webdumper.exe can not run on my Windows system (so it says).
I made some screenshots myself from a Sonoff running v2.0-20180112 and another ESP running v2.0-20180122,

[wdonker]

Looking at the code it seems impossible to switch the GPIO without log. That made me think that I did not check if pin state was actually changed.
I now found that the status in the device screen is updated but the GPIO is not switched at all, the pin state buffer stays empty.

Edit: I think the PluginCall at line 127 in _C002 is not executed.

[TD-er]

Hmm strike that... no clue what went wrong here...

[TD-er]

What MQTT message do you send to it?
And I am looking at these lines:
https://github.com/letscontrolit/ESPEasy/blob/19429e85079ca01d27ef8ecaced0037a33cf2b96/src/_C002.ino#L60-L69
And I don't get it with the "nvalue" which is assigned to float nvalue and long nvaluealt.

[TD-er]

Oh and can you delete the switch plugin and add it again? Just as a test. (you now have the screenshots ;) )

[wdonker]

Ok, I deleted the MQTT helper and added it again, no change.
The MQTT messages for switchon is:
MQTT : Payload: { "Battery" : 255, "RSSI" : 12, "description" : "", "dtype" : "Light/Switch", "id" : "00014097", "idx" : 71, "name" : "Test", "nvalue" : 1, "stype" : "Switch", "svalue1" : "0", "switchType" : "On/Off"

and for switchoff:
MQTT : Payload: { "Battery" : 255, "RSSI" : 12, "description" : "", "dtype" : "Light/Switch", "id" : "00014097", "idx" : 71, "name" : "Test", "nvalue" : 0, "stype" : "Switch", "svalue1" : "0", "switchType" : "On/Off"

So, nvalue contains the value of the switch and the svalue1 is not used (at least not for on/off, I saw that for a dimmer it contains the dimming level).

I think nvaluealt serves no purpose; the same value is assigned to nvalue and nvaluealt. Maybe it is a leftover from earlier versions of this code.

One other remark: the 20180112-version of _C002 loops through the list of controllers to find the right one. But it does so for every task (it's inside the 'task-loop'). I think this is not necessary since the controllers will not be different for different tasks and only one controller can be MQTT. So it can be done before looping through the tasks.

[TD-er]

I was talking about the switch plugin (P001)

[TD-er]

It is finding the task with a given idx. (Domoticz specific)
And in the latest code I changed it into a search for the controller ID before the big for loop, like you said.
Only thing is, P029 does not have a controller set to it.
And I think the check should be a little different:
change:
if (Settings.TaskDeviceEnabled[x] && Settings.TaskDeviceID[ControllerID][x] == idx) // get idx for our controller index

into:

              if (Settings.TaskDeviceEnabled[x] && 
((Settings.TaskDeviceID[ControllerID][x] == idx)  || (Settings.TaskDeviceNumber[x] == 29)))

[wdonker]

I think we have to process the tasks that:

• are enabled AND
• whose TaskDeviceId is the idx in the mqtt message and
• whose TaskDeviceNumber is 1 or 29.
  The code that is now (23-01 9:40) on GitHub seems to do so.
  Since recently I can compile ESPEasy myself, I will use this version and test.

Oh, and I do not use a P001 device in this situation, only P029.

[TD-er]

But P029 is just a pass-through (I guess, never used it, just looked at the code) to catch the MQTT message and send it to the device with the idx value set.
So if you don't have a device (called task in ESPeasy) with that idx value, it will not send it to that device.

[wdonker]

No, P029 is meant to intercept the standard Domoticz MQTT message and set a GPIO that is defined in the task.
So, Domoticz sends a message with idx (deviceid in Domoticz) and P029/C002 sets the according GPIO.

[TD-er]

OK, then I will have to have fresh a look at it again.

[wdonker]

Ok, I tested somewhat myself and I think the error must be somewhere in the case-construct.
I added some serial.println's and saw that the case 29 is entered with switchtype 'On/Off' (which is good) but it does not seem to reach the 'else' where the gpio action is formed.

Sorry for the bad explanation; I wanted to insert some code but it does not keep the lines (something with linefeeds I guess).

[TD-er]

OK, will have a look at it.
Sounds like something I may have introduced in another fix.

[wdonker]

Correction: it does reach the part where the action is constructed but it seems that this is only valid inside the case-block. My C++ is not that good, but can it be that the duplicate declaration (inside and outside the case-statement is the cause of this?

[TD-er]

You are absolutely right. That's my fault and totally overlooked yesterday evening.
That's the bug. Remove the String type before the action within the scope of the switch statement and it should work again.

[wdonker]

Yes, that did the trick. I'll test with a dimmer later tonight.

[TD-er]

I've added the fixes you found :)

[wdonker]

Glad to be of help.

I just tested a dimmer and, as expected, that is ok too.

[TD-er]

So this issue can be closed?

[Grovkillen]

Yes, I close it.