Seems like a network issue. I assume you have the right IP address! 
Just make sure you don’t have any extra extraneous spaces at the end of your MQTT Broker IP Address in the device Settings screen.
If you can install something like MQTT Explorer or some other MQTT client on your Ubuntu machine, you can use that to try and connect to your broker to verify it is reachable from there.
Yes, it sure looks like network issue.
I installed mosquitto on a Raspberry Pi 400. I can’t get to it either.
wptracy@wptracy:~$ mosquitto_sub -h 10.0.0.233 -t “mqtt/pimylifeup”
Error: Connection refused
wptracy@wptracy:~$
I also installed MQTT Explorer on my Ubuntu PC. I’m able to get out to test.mosquitto.org
That’s weird! Is there anything unusual about your network configuration?:
It’s fixed now.
MQTT Broker works now and I got the Shelly Flood device working. Thanks for the instructions above. I get SMS alerts form smartthings.
I found this link:
It says:
Starting with the release of Mosquitto version 2.0.0 (you are running v2.0.2) the default config will only bind to localhost as a move to a more secure default posture.
If you want to be able to access the broker from other machines you will need to explicitly edit the config files to either add a new listener that binds to the external IP address (or 0.0.0.0) or add a bind entry for the default listener.
By default it will also only allow anonymous connections (without username/password) from localhost, to allow anonymous from remote add:
allow_anonymous true
More details can be found in the 2.0 release notes here
To fix it, I added the following to /etc/mosquitto/mosquitto.conf,
and restarted mosquitto by, sudo systemctl restart mosquitto.service
pi@raspberrypi:~ $ sudo systemctl restart mosquitto.service
pi@raspberrypi:~ $ cat /etc/mosquitto/mosquitto.conf
# Place your local configuration in /etc/mosquitto/conf.d/
#
# A full description of the configuration file is at
# /usr/share/doc/mosquitto/examples/mosquitto.conf.example
pid_file /run/mosquitto/mosquitto.pid
allow_anonymous true
listener 1883
persistence true
persistence_location /var/lib/mosquitto/
log_dest file /var/log/mosquitto/mosquitto.log
include_dir /etc/mosquitto/conf.d
pi@raspberrypi:~ $
023-01-06T21:23:11.237670863+00:00 TRACE Shelly Flood MQTT V1 Received event with handler device_lifecycle
2023-01-06T21:23:11.242989488+00:00 INFO Shelly Flood MQTT V1 <Device: d4272d16-f4a2-4a20-943c-247e34737357 (Shelly MQTT Master)> received lifecycle event: infoChanged
2023-01-06T21:23:11.248459030+00:00 TRACE Shelly Flood MQTT V1 Found DeviceLifecycleDispatcher handler in Shelly Flood MQTT
2023-01-06T21:23:11.251494613+00:00 DEBUG Shelly Flood MQTT V1 Info changed handler invoked
2023-01-06T21:23:11.254557821+00:00 INFO Shelly Flood MQTT V1 Broker URI changed to: 10.0.0.3
2023-01-06T21:23:11.257759530+00:00 DEBUG Shelly Flood MQTT V1 Shelly MQTT Master device thread event handled
2023-01-06T21:23:17.096002612+00:00 INFO Shelly Flood MQTT V1 Attempting to reconnect to broker…
2023-01-06T21:23:17.140831070+00:00 INFO Shelly Flood MQTT V1 Connected to MQTT broker: CONNACK{type=2, sp=false, rc=0}
2023-01-06T21:23:17.145453528+00:00 INFO Shelly Flood MQTT V1 <Device: d4272d16-f4a2-4a20-943c-247e34737357 (Shelly MQTT Master)> emitting event: {“attribute_id”:“status”,“capability_id”:“partyvoice23922.status”,“component_id”:“main”,“state”:{“value”:“Connected to Broker”}}
Wow excellent finding! Glad you found this. I expect many others may run into this as well. I’m going to post a link to your post back in the MQTT topic.
Thanks!
Good idea. Thanks.
Regarding the Door & Window device: the documentation does not explicitly say that it keeps its wifi shut down most of the time. For the Flood and H&T devices it specifically says that. So I don’t know for sure if it does or doesn’t (I don’t have one). If it doesn’t stay asleep, then my standard Shelly driver should actually work OK for that device. However, one would think that with a battery it would HAVE to stay asleep, but who knows…
Can you give it a shot with the Shelly Device Driver V1.6 driver? It it can’t even connect to it once you configure the IP address, or it doesn’t maintain proper status in the SmartThings device over a period of time, then that would confirm it indeed stays asleep and needs the separate MQTT driver.
I’ve got the ShellyD&W configured on the Shelly Device Driver V1.6. It doesn’t trigger smartthing. I have a logcat running on Shelly Device Driver V1.6. I see no traces, but I know it works because I see the action on my Shelly App. I’ll include the screenshot below.
The device is supposed to be able to send an HTTP message when activated. It wakes up long enough to send a message.
Can you create a message like the one you have in ShellyMotion2.
http://10.0.0.223:51999/1e792e69-4d00-4232-aafc-1e65498d3d22/motion/active
Do I need to subscribe to something to be notified when you have a new device for D&W and H&T.
Cwptracy@wptracy:~$ smartthings edge:drivers:logcat --hub-address=10.0.0.223 -t b2774eb9-0ce4-…
──────────────────────────────────────────────────────────────────────────
──────────────────────────────────────────────────────────────────────────
1 e67c842f-49a5-4083-95f0-c8137ae3c2f6 Edge Counter Utility V1
2 6175f7c6-3a78-4625-a042-127a0e1c6f08 Edgebridge Monitor V1
3 7a236882-7479-4a21-b814-d40bbd53619f HTTP Devices V1
4 e8a1a0b7-32e4-4882-8d38-45a96ead543d LAN Motion Device Driver
5 8f390da7-c66d-4245-9ba9-e431f95c78ec Shelly Device Driver V1.6
──────────────────────────────────────────────────────────────────────────
6 782cce9b-dd7f-427f-993c-c9aec8dfb160 Shelly Flood MQTT V1
7 f3258c1d-b6e9-424d-8b3f-b1e8fe51c4ca Shelly Gen2 Device Driver V1.0
8 0fd9a9a4-8863-4a83-97a7-5a288ff0f5a6 Virtual Devices V2
9 a7d4ff68-2e8b-41f7-9be7-62bbe70f88f8 Web Requestor Multi v1.2
10 d58d8432-ea22-4d38-8300-2bd75fdf1358 Z-Wave Sensor
──────────────────────────────────────────────────────────────────────────
11 2cbf55e3-dbc2-48a2-8be5-4c3ce756b692 Z-Wave Switch
12 408981c2-91d4-4dfc-bbfb-84ca0205d993 Zigbee Contact
13 f82dec82-e5fa-487f-8f0f-22c3e4a8bd89 Zigbee Water Leak Sensor
──────────────────────────────────────────────────────────────────────────
? Select a driver. 5
connecting… connected
@wptracy Reminder - whenever you get the chance…
Can you do me a favor and do this:
Fire up logging and keep it running for the following steps:
If you could then send me the log of that activity I can confirm what is/isn’t happening.
Please send the log to me in a direct message rather than filling up the main topic here. And also, when you paste the text into the post, begin and end the log text with triple back-ticks (```) to help with formatting.
Thanks!
I’ll post an announcement here when I have the new MQTT driver ready. I have it working well for Flood and H&T devices, but want to wait and confirm if I need to add the D&W device. Thanks for your help on that.
you mean I can get the H&T device working now?
Sit tight, I haven’t made the driver available yet.
Let’s sort the D&W device situation first.
Thanks for all your work on this. Am I missing something, or is there a way to get Power (W) from the Shelly EM into the Energy dashboard to track energy consumption?
I’ve tried in the past to get this working with the SmartThings energy dashboard, but that feature is only supporting Samsung appliance devices.
All - I’ve pushed out an update to the GEN1 Shelly Driver.
As some have reported (@Diegocampy), it can occasionally happen that the Shelly device goes offline for whatever reason and/or loses its configuration that tells it to keep the Edge driver updated with state changes.
This update implements a check every 30 minutes to make sure the Shelly device is (a) still responding and (b) is still configured to send state change updates to the Edge driver. If either are not true, then the device will be reinitialized if possible. If it is still not answering, the driver will re-attempt to initialize the device every 10 minutes.
I hope this addresses some of these cases where devices stop working. It may not fix everything; for example if there is a problem with the driver itself that takes a hub reboot, then that’s a different problem.
This update will be made automatically to your hubs. No action is needed, other than to let me know if you run in to any issues, or things seem to be a bit more reliable over the long term.
Updated Driver Version: 2023-01-09T22:58:30.991090192
Interesting, I’ll keep an eye on how it performs.
I’m a little dubious about trying to reconnect every 10 minutes if something is wrong. In case as you say, it’s the hub to reboot that’s the problem, the drive will retry every 10 minutes indefinitely. I still remember that I’m not a programmer, so forgive me if I say nonsense: it would be possible to set a notification if not immediately, maybe after a couple of attempts. (even immediately if it were easier to manage the notification, and btw when I say notification I mean anything that can warn me if there are other possibilities)
I hear you. The problem is that we really don’t know the cause of your specific issue without logs.
As far as notifications, Edge drivers don’t have any access to do that; it requires an automation or SmartApp. I have contemplated two options: 1) setting the device to an ‘offline’ status when it can’t reach the device, or 2) adding a status field to the device that would show any issues.
#1 is easy to do, but problematic because once you set a device to offline, you can no longer use any of the controls. I don’t love that because even if the device is no longer updating SmartThings, you might be able to still control it. If offline, you wouldn’t even be able to try the refresh button.
#2 is probably the best way to go, but is a LOT of work to go back and change 20 device profiles. But it can, and probably should, be done.
I can survive without it, but if you can it would be appreciated 
NEW DRIVER AVAILABLE FOR GEN1 BATTERY POWER DEVICES
It has become clear that the majority of the Shelly devices that are battery powered do not stay awake to listen to wifi. Therefore the devices cannot be asynchronously awoken with HTTP commands or initialization requests. As such, my Gen1 driver, which uses HTTP, is not suitable for supporting them.
The exceptions to this rule are the Motion sensors (both original and Motion 2), which, although are battery powered, DO stay awake on the network and work fine with my existing driver.
** EDIT:** This may no longer be the case; please let me know if you use the motion devices and what your experience is. I will be adding support for motion devices to this driver.
Instead of using HTTP to communicate with the ‘sleepy’ battery powered devices, a more suitable approach is to use MQTT. And so I have developed a new driver that supports the Flood, Smoke, Button, Humidity&Temp, and Door&Window devices using MQTT.
10/18/23 EDIT: Now also supports Shelly Motion 1 and Motion 2 devices.
This requires an MQTT broker running on your network, which I know is not feasible for many of you, but unfortunately it is really the only way to integrate these devices.
The new driver is called Shelly Gen1 MQTT V1 and is now available on my test channel. I hope to get it moved to my regular shared channel soon, but want a couple weeks of user testing first. I also haven’t created a github repository for this yet.
If anyone is in a position to test these, I look forward to your feedback.
Instructions for Use
First, you will have to use the Shelly app to enable MQTT for the devices you want to integrate. This is done in the device settings menus.
All shelly devices publish their messages on an MQTT topic that begins with ‘shellies/’, therefore if you want to test to confirm your device is publishing updates to MQTT, you can subscribe to that top-level topic using a command like this (if using Mosquitto):
mosquitto_sub -v -h <ip address of broker or 'localhost' if on same computer> -t "shellies/#" -u <userid> -P <password>
Omit the userid & password parameters if not needed.
Once the Edge driver is available on your hub, do an Add device / Scan for nearby devices and a device called ‘Shelly MQTT Master’ will be created, and you will need to go into device settings and configure your broker information. Back on the Controls screen, you should see a status of “Connected to Broker”. Once you complete this, you can start onboarding your devices.
Since these battery-powered devices have to be woken up during discovery, you will physically have to go to the device and press its ‘wake’ button, but first initiate an Add device / Scan for nearby devices in the SmartThings app. Then press the button on the device. The supported devices listed above will be discovered and added as new devices.
That’s really all there is to it. There are no commands to be issued to these devices, only display of state data on the SmartThings device Controls screen, which is sent out by the device whenever it chooses to wake up. Of course all device states are available for automation routines.
Hi,
there have probably already been changes on the side of smartthings and actiontiles, but the result is that no components from the UNI shell were loaded, only “main”, which means I lost the display of temperature and humidity in actiontiles. I will try to contact actiontiles about what the problem is. if actiontiles couldn’t solve it, could the sensors be moved as you wrote earlier?
