GPIO port#255 is out of range using Domoticz MQTT Helper

[urkelbundy]

Hi all,

Latest built used, ESP_Easy_mega_20201125_normal_ESP8266_4M1M.bin

I configured Domoticz MQTT Helper without using a GPIO pin. The status of the IDX that is configured in the Helper is used in rules to switch on/off the backlight of a LCD2004. The log shows GPIO port#255 is out of range when the status changes.

When a GPIO is configured in the Helper the out of range message is no longer shown but it wastes a GPIO pin

[TD-er]

Can you give the exact command you're giving?

[urkelbundy]

I assume you mean in rules.

on LCD-Backlight#Output do if [LCD-Backlight#Output]=0 lcdcmd,off else lcdcmd,on endif endon

[urkelbundy]

I noticed that it is no longer possible to enter a "-" in the name of the Helper. The - that is still in the rules above is no longer in my rules. The rules do not cause the out of range message, it is the configuration of the Helper as shown in the screenshot

I do not know how I did it, but the output of the Helper now seems to be a float!?!? Shouldn't that be just 0 or 1? I was trying to find another way to switch the backlight on/off using the Generic - MQTT Import plugin. Maybe that has something to do with it??

[TD-er]

Hmm the nr of decimals in the MQTT helper is very likely a bug I introduced in a recent change where I now try to initialize the values properly... but may have forgotten to set it explicitly to some non standard default when you add a new task.

[TD-er]

Can you test if this fixes it?

• ESPEasy_ESP32_mega-20201125-4-PR_3395.zip
• ESPEasy_ESP82xx_mega-20201125-4-PR_3395.zip

[urkelbundy]

The GPIO out of range in the log is still there.

I cannot reproduce the float in the Helper anymore so that seems to be fixed although I am not entirely sure how to reproduce it.

[TD-er]

The fix I applied was mainly focussed on that number of decimals you saw. This test was mainly to make sure the extra decimals did not cause the bug, but apparently it doesn't.

So we have to continue to search for the true cause of this issue here.

What are you trying to send from Domoticz to the ESP? Is it a dimmer or a switch?

Can you try to fetch more of the logs surrounding this error? The error you mention is possible from quite a lot of GPIO related commands.

[urkelbundy]

It is a switch. I will try to get more info from the log

[urkelbundy]

Loglevel at debug dev shows little more. 5720346: Command: gpio 5720348: GPIO port#255 is out of range

[TD-er]

Is that the only log? It should show the complete command including parameters.

[urkelbundy]

461933: Command: gpio 461935: GPIO port#255 is out of range 461953: EVENT: LCDBacklight#Output=0 461966: ACT : lcdcmd,off 461967: Command: lcdcmd

[giig1967g]

I suspect that 255 is a -1 converted to "byte" type.

461933: Command: gpio 461935: GPIO port#255 is out of range 461953: EVENT: LCDBacklight#Output=0 461966: ACT : lcdcmd,off 461967: Command: lcdcmd

If there is no ACT: gpio.... in the log, it means that the GPIO command is sent internally somewhere. Not from a rules command

[TD-er]

I added an extra debug log for which the entire command is logged. Build is started, I will have a test build for you in +/- 20 minutes

An exacmple of a log sent via the web interface, to show how it will appear in the logs:

44611 : Info   :  Webserver args: 0: 'cmd' length: 8
44614 : Info   : HTTP: gpio,255
44620 : Error  : GPIO : port#255 is out of range
44622 : Error  : gpio,255

[giig1967g]

It could be that it has always been like that, but simply before it was not displayed

[TD-er]

What build are you running? I don't see the debug log, from the Domoticz MQTT controller, suggesting you either run a "test" or a "dev" build. Please try with a "normal" or "custom" build.

[TD-er]

I think it has to do with this piece of code in the case CPlugin::Function::CPLUGIN_PROTOCOL_RECV of Domoticz MQTT:

https://github.com/letscontrolit/ESPEasy/blob/5e64afa09c1fb9c4f3f5624dfde8eb3e6002f824/src/_C002.ino#L103-L176

Case 29 is the Domoticz output helper plugin. So if it finds that plugin, it will take the Settings.TaskDevicePin1[x], which is set to -1, casted to uint8_t is 255. N.B. it calls bool checkValidPortRange(pluginID_t pluginID, byte port) type byte is uint8_t

[urkelbundy]

Build:⋄	20111 - Mega
System Libraries:⋄	ESP82xx Core 2843a5ac, NONOS SDK 2.2.2-dev(38a443e), LWIP: 2.1.2 PUYA support
Git Build:⋄
Plugin Count:⋄	46 [Normal]
Build Origin:	Travis
Build Time:⋄	Nov 26 2020 10:56:26
Binary Filename:⋄	ESP_Easy_mega_20201126_normal_ESP8266_4M1M
Build Platform:⋄	Linux-4.19.104-microsoft-standard-x86_64-with-glibc2.29
Git HEAD:⋄	HEAD_172b758

[giig1967g]

@TD-er could it be that is because "inputswitchstate" has been deprecated?

[TD-er]

@TD-er could it be that is because "inputswitchstate" has been deprecated?

Nope, it does look like a false positive error. This because we don't check for a valid GPIO when generating the command (in C002, line 145). On top of that the error is a bit malformed because we're using uint8_t in the error log function and also in the checkValidPortRange function (output of that function does not change when giving a GPIO '-1')

[TD-er]

I just made a commit to fix this and thus restart a new build (estimated build time is ~20 minutes)

P029 Domoticz MQTT helper does allow to not use a GPIO pin. The pin number is then set to -1. Typical use case is to only act on the event generated by the helper plugin. Therefore it is a valid situation and should not pollute the logs.

[TD-er]

New test build.

• ESPEasy_ESP32_mega-20201125-7-PR_3395.zip
• ESPEasy_ESP82xx_mega-20201125-7-PR_3395.zip

[urkelbundy]

It is fixed. No more out of range messages in the log.

Many thanks.

[giig1967g]

@TD-er I have been thinking, but why have you just removed the error message instead of checking the value before sending the gpio command:

ESPEasy/src/_C002.ino
Line 142
                   } else { 
                     if (Settings.TaskDevicePin1[x]>=0) {
                        UserVar[baseVar] = nvalue; 
                        action           = F("gpio,"); 
                        action          += Settings.TaskDevicePin1[x]; 
                        action          += ','; 
                        action          += static_cast<int>(nvalue); 
                   } 
                }

I would have left the GPIO out of range error message in case GPIO is negative, otherwise a user that sends by mistake the GPIO,-1,0 command (maybe because he's using variables and do not realize the number is negative) would not get any error in the log and might be confused...

Just my 2 cents

[TD-er]

If the action string is empty, no event will be sent. Also I don't know if it is also possible via other routes to receive gpio commands, so the logs should at least be able to handle a "-1" value as GPIO pin as that's being used all over the software indicating "none". The functionality of this specific plugin is completely void if it only can act on a real GPIO pin. You still need to have the event so you can process it in the rules, like it is acting on a virtual GPIO pin.

Sure I can add bool flags like validCommand and mustSendEvent, which does make sense. But still you need to have the GPIO commands being able to handle the "-1" pin as it is very likely it will be called via some other route too as it is the "none" pin all over our software.

[TD-er]

I updated the code for C002 to no longer try to execute the command if the GPIO is invalid.

[tonhuisman]

This seems to be solved, issue can be closed.