Hauptmenü

MQTT reading

Begonnen von jacko, 22 März 2025, 07:42:26

Vorheriges Thema - Nächstes Thema

jacko

I have a shelly1 Gen3 device I am trying to control using MQTT, but am having some problems.

I can send a mqtt message to the device to switch it on/off using the setList:
off TyG/shelly1/command/switch:0 off
on TyG/shelly1/command/switch:0 on

and I can see the switch response in the MQTT2_DEVICE traffic
06:11:25.409 RCVD TyG/shelly1/status/switch_0 {"id":0, "source":"WS_in", "output":false,"temperature":{"tC":42.6, "tF":108.6}}I noticed that the "switch:0" in the topic has been replaced by "switch_0" in the received message. Not sure why.

But I can't get the shelly MQTT device to trigger and decode this response. I have the readingList
attr Lights readingList TyG/shelly1/status/switch_0 .*which I thought would return all the readings and show in the Readings, which it did 1 time only giving me
Readings
IODev GDTyGBroker 2025-03-22 05:35:29
outputid 0 2025-03-22 06:20:48
outputoutput false 2025-03-22 06:20:48
outputsource WS_in 2025-03-22 06:20:48
outputtemperature_tC 42.5 2025-03-22 06:20:48
outputtemperature_tF 108.6 2025-03-22 06:20:48
state off 2025-03-22 06:05:49

This did at least give me the reading to trigger the change using event-on-change-reading "outputoutput". Not sure why the output is repeated?

Once I get the device responding to the mqtt message I will obviously need to extract the switch "output" from the json construct. Here also I have some confusion. Looking around there seem to be multiple ways of doing it, but of course I can't experiment yet because of the basic triggering problem I have.

My instance has been updated to the latest FHEM version.

BTW, I am having to use mqtt to control the shelly as the FHEM Shelly module doesn't seem to support Gen 3 devices. Is there any plan to update it?

Any help or pointers would be appreciated.

Beta-User

Zitat von: jacko am 22 März 2025, 07:42:26BTW, I am having to use mqtt to control the shelly as the FHEM Shelly module doesn't seem to support Gen 3 devices. Is there any plan to update it?
Afaik, the (development?) Shelly module should also support 3rd gen models, see e.g. https://forum.fhem.de/index.php?topic=137222.0

Using MQTT is also possible, but the JSON decoding of the 3rd gen devices is quite complicated. Nevertheless there's some attrTemplate prepared to help. But as you have changed the default topic the shelly uses, you may not see them...
Have a look at the source code of mqtt2.template (starting with the line "# SHELLY plus section").
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

jacko

Thanks for the quick replies.

I can see that now I have done an update that the Shelly1 Gen3 is supported (I had tried before the update). I have created a Shelly device and it works OK from within FHEM. However, if the shelly device changes state (by another source, eg the shelly web interface or a mqtt  message from another source) then the fhem shelly instance does not update. This is what I am trying to achieve. I want the fhem status to reflect the actual device (switch relay) at all times. I did add a state change update attribute.

Thank you for the pointer to the mqtt2.template. I had been attempting to use something similar to the suggested readingList parsing before I realised that the mqtt messages were just not being processed by the reading list (as the .* was not creating a $EVENT each time the message topic was received).

Either option (mqtt of Shelly device) would work for me - I just need to get the fhem device to respond to the state changes and update the fhem device state.

Any further suggestions?

rudolfkoenig

Not a solution to your problem, just some explanations:

ZitatI noticed that the "switch:0" in the topic has been replaced by "switch_0" in the received message. Not sure why.
Historic reasons. See https://fhem.de/commandref_modular.html#MQTT2_SERVER-attr-topicConversion

Zitatattr Lights readingList TyG/shelly1/status/switch_0 .*
My current working hypothesis:
The first argument in readingList is a regexp, and must match either the received topic:payload or mqtt-clientid:topic:payload.
As this is never the case with the given regexp (TyG/shelly1/status/switch_0), and autocreate is active, readingList will be expanded with
TyG/shelly1/status/switch_0:.* { json2nameValue($EVENT) }
which in turn results in the mentioned readings.
See also https://fhem.de/commandref_modular.html#MQTT2_DEVICE-attr-readingList

ZitatNot sure why the output is repeated?
Cannot tell you, as I do not have all the definitions, attributes and input data to reproduce it.

jacko

Just closing the loop...

I had a missing ":" after the mqtt topic!

My reading list is now
TyGarwen/shelly1/status/switch_0:.* { $EVENT =~ s/"output":true/"state":"on"/g; $EVENT =~ s/"output":false/"state":"off"/g; json2nameValue($EVENT) }
and this gives me the desired behaviour of setting the status correctly whatever source updates the switch relay.

Thanks for the pointers. Sometimes looking at other examples makes a big difference.