How To Find Cause of MQTT Problem, Need Help Please

tacticaljack · March 15, 2021, 4:56pm

Using SONOFF Dual to control rollershutters. Some of them keep generating the following an MQTT error, I think related to shutter position. The error is:

MQTT message received. MqttMessageSubscriber#processMessage() implementation failure
java.lang.IllegalArgumentException: Value must be between 0 and 100

I have looked at the SONOFF console and MQTT payloads … everything appears to be correctly formatted with the correct 0-100 position values.

How do I track down the source of this error?

“thing”

Thing mqtt:topic:eab2edb0:RS_LRw_Window "RS_LRw_Window" (mqtt:broker:eab2edb0) @ "Living Room" {
    Channels:
        Type rollershutter : rschannel "Shutter" [ 
	    commandTopic="cmnd/RS_LRw_Window/shutterposition1", 
	    stateTopic="stat/RS_LRw_Window/SHUTTER1",
	    up="up",
	    down="down",   
            stop="stop"     
	]
        Type switch : reachable "Available" [
	    stateTopic="tele/RS_LRw_Window/LWT",
            on="Online",
	    off="Offline"
        ]
	Type number: position "Shutter Position" [
	    stateTopic="tele/RS_LRw_Window/SENSOR",
	    transformationPattern="JSONPATH:$.Shutter1.Position"
	]
	Type number:rssi "RSSI" [
	    stateTopic="tele/RS_LRw_Window/STATE",
	    transformationPattern="JSONPATH:$.Wifi.RSSI"
	]
	Type switch: uppower "Shutter Up" [
	    stateTopic="stat/RS_LRw_Window/POWER1"
	]
	Type switch: downpower "Shutter Down" [
	    stateTopic="stat/RS_LRw_Window/POWER2"
	]
}

“item”

Rollershutter Shutter_LRw_Window "LR West Window Shutter" (gExerciseShutters, gLivingDome, gAllShutters) { channel="mqtt:topic:eab2edb0:RS_LRw_Window:rschannel" }

I have tried defining the “item” with one and two channels.

“item” with 2 channels

Rollershutter Shutter_LRw_Window "LR West Window Shutter" (gExerciseShutters, gLivingDome, gAllShutters) { channel="mqtt:topic:eab2edb0:RS_LRw_Window:rschannel", channel="mqtt:topic:eab2edb0:RS_LRw_Window:position" }

rossko57 · March 15, 2021, 5:48pm

can we see the MQTT package?

tacticaljack · March 15, 2021, 6:01pm

Here is info from MQTT Explorer…

Here is from Tasmota SONOFF Dual console log…

Here is the relevant item on Basic UI. The position value is correctly displayed, yet an error like the one originally shown, was thrown. Can not prove it is a direct result of moving this shutter, but that is all that I did.

tacticaljack · March 15, 2021, 6:15pm

Later today, I will try to determine which SONOFF is triggering this error. I can probably use the log timestamp and the SONOFF console time stamp to determine the device. If I am successful, I will upload the relevant data.

rossko57 · March 15, 2021, 7:45pm

Yes, it’s a great nuisance that the binding does not report the channel with the complaint, playing detective is necessary.

tacticaljack · March 15, 2021, 8:26pm

Yes it is a pain. It appears that I will be able to sync up the timestamps from the openhab.log and the Tasmota console log and be able to determine the offending device. Some chores have delayed my research until tomorrow.

tacticaljack · March 15, 2021, 11:10pm

OK, I had time… here is what I’ve found.

Front door shutter is showing 29% closed, pantry door shutter showing 85% closed, on the Basic UI. I have the error from openhablog and the SONOFF console log. I do not see any problems with the data for its format, yet the errors continue to be thrown when the shutters are at a non-zero position. Both of these shutter items are defined with 2 channels, not 1.

2021-03-15 17:58:01.902 [ERROR] [ansport.mqtt.internal.ClientCallback] - MQTT message received. MqttMessageSubscriber#processMessage() implementation failure

java.lang.IllegalArgumentException: Value must be between 0 and 100

	at org.eclipse.smarthome.core.library.types.PercentType.validateValue(PercentType.java:57) ~[?:?]
	at org.eclipse.smarthome.core.library.types.PercentType.<init>(PercentType.java:52) ~[?:?]
	at org.eclipse.smarthome.core.library.types.DecimalType.as(DecimalType.java:152) ~[?:?]

17:58:01 MQT: tele/RS_Front_Door/STATE = {"Time":"2021-03-15T17:58:01","Uptime":"1T22:50:23","UptimeSec":168623,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":8,"POWER1":"OFF","POWER2":"OFF","Wifi":{"AP":1,"SSId":"DomeMesh","BSSId":"00:11:32:C3:94:29","Channel":5,"RSSI":70,"Signal":-65,"LinkCount":8,"Downtime":"0T00:01:16"}}
17:58:01 MQT: tele/RS_Front_Door/SENSOR = {"Time":"2021-03-15T17:58:01","Shutter1":{"Position":29,"Direction":0,"Target":29}}

or it could be this one, both are at non-zero positions…

17:57:58 MQT: tele/RS_Pantry_Door/STATE = {"Time":"2021-03-15T17:57:58","Uptime":"12T00:23:51","UptimeSec":1038231,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":53,"POWER1":"OFF","POWER2":"OFF","Wifi":{"AP":1,"SSId":"DomeMesh","BSSId":"00:11:32:C3:94:29","Channel":5,"RSSI":56,"Signal":-72,"LinkCount":45,"Downtime":"0T00:04:44"}}
17:57:58 MQT: tele/RS_Pantry_Door/SENSOR = {"Time":"2021-03-15T17:57:58","Shutter1":{"Position":85,"Direction":0,"Target":85}}

denominator · March 15, 2021, 11:50pm

You may need to use regex to filter out the unwanted data going into your item.

Tasmota puts multiple types of messages into the Result topic you can change this with setoption4

rossko57 · March 16, 2021, 1:08am

None of the channels shown are subscribed to RESULT topic.

The only channel shown with a 0-100 interest is the rollershutter one, subscribed to SHUTTER1 topic, and not showing any of those at this time.

denominator · March 16, 2021, 1:57am

True for the thing he posted in the OP. If you are sure that it is the roller shutter item and channel

        Type rollershutter : rschannel "Shutter" [ 
	    commandTopic="cmnd/RS_LRw_Window/shutterposition1", 
	    stateTopic="stat/RS_LRw_Window/SHUTTER1",
	    up="up",
	    down="down",   
            stop="stop"     
	]

Rollershutter Shutter_LRw_Window "LR West Window Shutter" (gExerciseShutters, gLivingDome, gAllShutters) { channel="mqtt:topic:eab2edb0:RS_LRw_Window:rschannel" }

This should work correctly

Its more likely a bug in the number type channel. When changing the channel types sometimes those settings don’t change correctly.

Try removing the position channel by commenting it out and see if the logged error goes away.

Joerg_Schreiner · March 16, 2021, 2:14am

Hi,
as documented in Tasmota Shutterposition only accepts numbers. 0 to 100 (percent).
If you want to send the up, down, stop commands, you have to define a channel with BACKLOG and then send SHUTTERCLOSE1, SHUTTEROPEN1 and SHUTTERSTOP1 as UP, DOWN and STOP.
In your case commandTopic="cmnd/RS_LRw_Window/backlog"

Joerg

tacticaljack · March 16, 2021, 8:09pm

OK, let me send my thanks for all of these replies. I’m going to take this input and work my system to see if I can solve this problem.

Afterwards, I’ll either close with a “SOLVED” or post follow-up questions. Again, thanks to everyone.

tacticaljack · March 17, 2021, 7:40pm

Progress report. The window shutter “Office” is causing the problem now. It is fully closed. It had the position channel defined. I have removed this channel from all of the rollershutter items. The errors have gone away.

Removed this…

channel="mqtt:topic:eab2edb0:RS_Office_Door:position

However, I am certain that I originally added this “position” channel in an attempt to correct another problem with the BasicUI rollershutter version of “switch”. I believe that it was a case where the position (0-100) on the switch was displaying as a dash “-”. I can not recall the conditions that triggered this issue.

When I run into the original problem again, I will open a new topic.

I will close this as solved tomorrow, when I am certain it has cleared up and stayed that way.

Thanks to everyone for their help and input.