Yes, I've also tried that driver; But as you can see, this one work's only with polling ("auto refresh" is driver integrated polling).
So I'm looking for other drivers...
Or I have to wait for a firmware change from Allterco Robotics - hoping that they would add something like an Action URL for Power Changed.
A trigger/action URL for "Power Changed" would potentially trigger tens/hundreds of times, I don't think it's the right approach. In your case I would suggest MQTT that is supported by Shelly Plug: API Reference
I thank you for your answer!
Of course, such an action URL would need a possibility to configure, what changes are worth to trigger, as they have already done with other sensors (e.g. tilt or light) - maybe in percent.
BTW: MQTT also uses polling behind the scenes.
You can use MQTT over Websockets (Mosquitto supports it) so it's server push, no polling.
How can Shelly and Hubitat come together via MQTT - without extra hardware?
Shelly has integrated MQTT support, check the links I provided you in previous post. So Shelly devices update MQTT topics.
You can then install MQTT Link and subscribe to Shelly topics via a virtual device: [RELEASE] Hubitat MQTT Link
MQTT Link is also available through Hubitat Package Manager app.
Obviously you need an MQTT broker, like Mosquitto, installed somewhere.
Or, you can use a free MQTT broker server on the internet, I use this one: Free Public MQTT 5 Broker Server | EMQ (emqx.io)
That's what I don't want! 
So long Hubitat is not capable of MQTT broking I really prefer to continue the polling 'until (maybe) Shelly changes it's firmware.
You want too many things. Adapt by integrating things or write your own stuff. 
An automation hub shouldn't be an MQTT broker. HA doesn't have a broker, IIRC: MQTT Broker - Home Assistant (home-assistant.io)
I agree that a client device push instead of polling to pull info is better, but can you explain why polling is actually a problem in this case? Could be lots of reasons: response time, concern about network traffic, concern about load on Hubitat, or others. Maybe by examining why you are concerned about polling you can identify the best approach to work within the integration options and constraints that are available.
Shelly does actually push, to an MQTT broker. And MQTT brokers support websockets, so they can also push to MQTT clients.
But I agree with you, if you have less than 50 devices, you can also poll without issues...
I'm not as well versed with MQTT, but from a quick glance at the Shelly implementation it seems to just be a periodic update which is configurable. Which from a responsiveness perspective is the same as a poll. And as you said, the difference in overhead between polling and handling the incoming ws seems negligible.
My takeaway: setting up MQTT just to get the data into Hubitat seems like a nonstarter compared to polling. Unless there is some downside to polling that is still problematic for @Jost.
Nope. It's not "periodic". It's an immediate push update. Nothing like polling, you don't set intervals, as soon as the Shelly has a new value it pushes it to the MQTT broker. That's what MQTT was designed for since the beginning. And now there's also Websockets, so also push to the MQTT client.
I don't agree: for monitoring power meters or sensors that provide info data, polling is inefficient. Best way is always a push to server method with subscribers that get data in realtime, and MQTT allows you to do exactly that. I use it for meteo data, it works perfectly.
This is what I read and was referencing:
Device state is reported periodically, every 30 seconds by default. This can be changed by setting a new period for updates:
mqtt_update_periodunder/settings. A value of0will disable periodic updates.
I like the action URLs that Shelly provides, which provide a pushed update when things like a switch or button is activated or a measurement exceeds a threshold. This seems to provide MQTT-like behavior as you described it.
I don't see such a threshold setting for things like this power and energy reporting with Shelly devices, so I assumed it was a periodically updated value.
This is the log of mqtt for my Shelly Plug that monitors my tv/ht in the living room, as you can see from the timestamps, the topics are updated each time there's a change in power/energy, it's not a fixed period, and I never touched the mqtt_update_period parameter, that is at 30sec default. That is a general parameter, each device type then has a specific behaviour. Monitoring devices send info at every change, and I expected this behaviour. I have 10 Shelly Plugs and 4 Shelly EMs monitoring power in my house, they all work the same way: power data is sent in realtime at every change.
Cool, good to know that it works that way. They appear to be using some hysteresis under the hood so that it isn't just constantly reporting new values. Looks like maybe ~20 watt increments. Could either be the behavior they programmed with an internal threshold for change or even just the resolution of the measurement (or both). Do you have enough data to determine whether they have consistent resolution on what increment of change is reported? This may tip me to take up MQTT for my personal Shelly drivers. Thanks for sharing.
Not going to happen.
Firmware updates incoming every month.
This will NEVER happen... There isn't enough memory in the devices to also include a MQTT broker.
I'm in the loop about any major changes since I write these drivers.....
Hey! Has anyone bought (or received) the new Shelly motion sensor? I'm really interested in buying a few, but it is important to me that i can integrate them into HE.
Download the Hubitat app
