Thank you! I had seen that example before – but wasn’t sure how to use it since I had the MQTT publishing “device” installed and didn’t have the temperature device.
I get it now, and after hydrating a virtual “mqtt temperature” device, I was able to use the exact rule text to call the setvTemp command and publish the update, which I have confirmed using MQTTX as a subscriber.
So, note to others who find this (and I didn’t even after reviewing all the threads / topics), you need to create a new virtual/child device using the mqtt parent first, plus create a matching copy for every one of the temperatures you want to publish to mqtt (our house has 8 or so). I’ll create a virtual “room” for them to hide them away.
Thanks again. Would have been nice to have a single mqtt bridge device, but I get it now based on what you said, the types cannot be converted in the rules engine.
The MQTT Devices driver crashes if a numeric value NaN is received via MQTT.
My RPi Python program sends the temperature values using MQTT to the ST Hub.
From the source of the temperature values became a NaN value
and the Python program sent it with the MQTT Retain flag.
This caused the driver to crash constantly. The driver received a NaN value as a response immediately after driver started and started to update MQTT topics’ values.
Figuring out the fault was really challenging because the situation looked like a network failure.
I got a new router and even though I got my node red (mosquitto broker) running with a new IP address I can’t connect the Smartthings Device Handler to the broker. Does the IP address need to be 192.168.1.xxx? I have 192.168.68.xxx
I bought my first Shelly device this week.
The device is Shelly 1 Gen3.
I wanted to use local communications to ST Hub.
I didn’t want add more drivers to the Hub and decided to try MQTT communication.
I already had the MQTT Devices driver ready to use.
MQTT communication seems to work using MQTT Devices driver.
Here is a summary of Shelly’s settings for MQTT communication.
All Shelly Device settings are done using Shelly Device’s local web interface.
The Shelly 1 Gen4 has just released and includes Matter and Zigbee support out of the box so no need for anything fancy or custom drivers for local communication with SmartThings. Your Gen3 will also receive Matter update eventually.
I’m in no hurry to use Matter. The reliability of the Matter WiFi bulb (I have one Wiz bulb) is clearly worse than that of Zigbee bulbs.
The Matter WiFi bulb is offline almost every week.
MQTT’s reliability is on the same level as Zigbee.
Got it, Gen4 has Zigbee too in addition to Matter, I guess it’s worth it as first Shelly device to have more options.
MQTT if I understand correctly requires not only the SmartThings hub and this custom driver but another machine running 24/7 to run the MQTT broker.
I’m surprised with your experience with Matter lights, I have 9 WiZ and 3 Nanoleafs and don’t really remember if they’ve been offline in a year using the Aeotec hub. My Matter sensors have been stable too, except the Aqara P2 door sensor which goes offline for a couple minutes from time to time but that’s running a two years old firmware because Aqara.
I may be mistaken, but I think it’s the same radio, so when you set it up, you select either matter over thread or Zigbee. But not Zigbee with one coordinator and matter with another For the same device at the same time.
If I’m wrong on that, hopefully someone will let us know.
It’s one or the other indeed, by default it’s Matter and you can “Press 5 consecutive times to switch the Device from Matter firmware (default) to Zigbee”.
What I meant is that Gen4 not only has Matter but Zigbee too, both technologies with local connection to SmartThings.
