Shelly Device Handlers for Hubitat

⚙️ Custom Apps and Drivers Custom Drivers
522

Driver is updated with:

  • Password is now masked out
  • Fixed incorrect version stage for 'beta' update reports (showing them as 'stable'; update command itself is not affected)
  • Removed never changing 'devicePath' parameter

Virtual battery powered device:

  • Added 'powerSource' to more nicely describe charging process when available ('battery' or 'dc')
  • Added 'batteryState' attribute instead of 'alarmBattery' ("idle" or "discharging")
2 Likes
523

Nice to see some improvements, keep up doing the good work:-), thanks
Any progress or plans on those topics:

  • Renaming the link attribute to health status

  • I don't think it is easy for new users to find your repo
    Integrate it in HPM? Make a new topic?

  • Add the driver version, something similar as this:
    image

524

The better re-configuration is ready to some extent. Right now I have a version where only device addition takes place. I.e. "Configure" will have an option ("update" or "clean"). Yet it still lacks specific deivce removal (like in case of profile change to remove only "shade" (or only "switch") devices). [Not published yet]

And I have some initial draft on a "Shelly BLU gateway" app to manage bluetooth devices. Curently the idea is to register all of the gateway-capable devices (that should participate in bluetooth management) inside an app. Then an app will spawn virtual child devices for detected bluetooth sensors. I want to try to use an app as some sort of root to support kinda "migration" (meaning some BLE devices may be moved and report trough a different gateway device due to this)
Waiting for sample BLE device to "play" with.

1 Like
525

New driver update:

Configure ("update") now can remove unused child devices (except 'EM' component; WIP).

Added 'thermostat' component support for the Shelly Wall Display.
Support is incomplete as there is no documentation regarding related component nor code samples. All the new functionality is based on assumptions and device behavior observations. Setpoint is controllable, driver properly decodes unit settings changes. But on/off function is not currently working.

2 Likes
526

This the final solution! THX

527

@dmitry.rozovik any change you will add the health status so we can use it in the Device Activity Check and Device Watchdog apps?

528

I'm thinking on how to do that in a versatile way. Hubitat platform recently added a way to monitor custom health status as a custom row in the device list table. And I like this idea of making it configurable. To either somehow hook to this functionality (and forward to the health status attribute) or duplicate somehow.

It makes sense on a platform level as each and every device may have different attribute (and different meaning) to watch for a "healthy" device. It may be link status, it may be relay temperature or input voltage level, etc. It can be anything depending on context.

So I consider direct forward of the "link" attribute the health status attribute rather like a fallback if there will be no better (more flexible) solution.

(In a mean time driver is updated with healthStatus attribute)

================================================

A side of it I got H&T device (unfortunately device to test BLE gateway functionality is still on the way). It works a bit differently from what I imagined based on a documentation: basically it can't maintain websocket open as it is constantly in a sleep mode except periodic wakeups to update screen and send data to either cloud service and/or to trigger hooks.

To handle this without opening hub ports nor using Maker API I'm adding so called virtual child devices to the driver. Firts two will be temperature and humidity devices. The amount of them will be configured trough a parent device. The will get data from Shelly scripts using special event naming (script will be able to fire an event to the specific virtual child device if such type is supported or to the "variable" attribute otherwise to keep ability to workaround/forward using hub functionality).

Here is how it is going to work: Shelly H&T hooks will be set to trigger endpoints on some other plus/pro device (that is by nature permanently listening). This plus/pro device will have a shelly script that simply forwards hook to the driver trough its permanently open event stream to a specific virtual child device. And this way hub/driver will get instant temperature/humidity reading without cloud service and without exposing external access to the hub

Unfortunately it adds some complexity. But on the good side is the ability to make kinda isolated subnetwork of two (or more) devices that locally do some temperature/humidity automation that is immune to loosing hub connection for any reason.

2 Likes
529

Nice, thx for that, check this @kkossev :slight_smile:

Should it no be forwarded after X time offline?

Was there a change on the configure button with this new release?
If I read your plan with the H&T device, Is the goal to merge this in the existing driver or is it a separate driver?

530

It looks possible to implement.

Yes. As optimized child device addition/removal is working no point to keep two options. Driver will keep only relevant child devices.

Merge to an existing. A functionality to spawn virtual child is added already, Yet the arey not used atm. Currently script events are decoded as:

  • Shelly.emitEvent("number", value); --> script::customNumericAttribute
  • Shelly.emitEvent("string", value); ----> script::customTextAttribute
  • Shelly.emitEvent("text", value); ------> script::customTextAttribute
  • Shelly.emitEvent("variable", value); --> script::variable

Temperature and humidity most likely will be forwarded as something like:

  • Shelly.emitEvent("humidity:<X>", value); -----> virtualHumidityX::humidity
  • Shelly.emitEvent("temperature:<X>", value); --> virtualTemperatureX::temperature
1 Like
531

I'm sorry if this is lame but I'm using Shelly Switch Relay Driver https://github.com/ShellyUSA/Hubitat-Drivers/blob/master/Shelly-as-a-Switch.groovy to control my Shelly 1PM relay Shelly 1PM and it turns the relay on and off just fine.

First, is there some new driver I should be using for my older Shelly Shelly Gen 1 devices like the Shelly 1PM?

Second, the status in HE isn't alway up-to-date, since these relays also have a physical switch connected to them. It seems I could use the Maker API to have the relay update the HE status on occasion. Is it best to just push the "refresh" URL in the "Output On" and "Output Off" slots?

That is, if a HE Maker API url like this
http://192.168.88.110/apps/api/231/devices/138/refresh?access_token=
is called when the relay opens and closes from the physical switch control, will HE keep up to date on the status? Or is there a better approach.

Much thanks,

532

I think the small delay is something mandatory. When you have a mesh wifi system the mesh controller is changing channels of the accesponits what result in a schort disconnect, this is triggering the health status offline/online with a few seconds between.

533

You better use the system driver from Hubitat (for the gen1 devices) If you want the status updated in both directions.

534

Driver is updated:

'healthStatus' now has update delay. Needs to save/set preferences once after driver update to start functioning. (Newly installed device/driver should work out of the box)

2 Likes
535

Very nice, thx for that

536

Driver is updated:

  • Added experimental support for dimmer functionality for the upcoming Shelly Pro Dimmer xPM

  • Partial support is expected for the Shelly Plus Uni out of the box: digital inputs, relays, posibly temperature sensor support [no analog input support atm]

  • Gen3 devices seem to represent mostly hardware update and announced (but not yet available) 'matter' support. Expected to stay API compatible with Gen2 [one of them were successfully tested and confirmed fully working with this driver]

2 Likes
537

Hi @dmitry.rozovik, I have been using the built-in HE driver for my Shelly Dimmer 2's. Do you have a better driver available? I can't see one listed on your github page

538

Hello @rhodesda,

Unfortunately my driver/bundle has no support for Gen1 devices. My driver is relying on a functionality that is only present starting Gen2 devices.

Maybe thread main repository has something you could use. Like Shelly-Vintage that is also a dimmer device.

1 Like
539

I keep getting the message about not being able to process the bundle.
image

Also downloaded the file and tried again. Same error.

A hub reboot didn't help.
A hub reboot and database rebuild didn't help.

I had an old Shelly driver manually installed before but I removed both the device and the driver.

Any suggestions?

540

Hello,

The only thing that comes to my mind is possibly a file name clash with some other/older driver file.
Just in case please try this link: https://bitbucket.org/ge4d/hubitat-code/raw/f5d03aa04c9069011141512a7732b22f97676738/Bundles/Bundle1.zip

@bertabcd1234 @bobbyD
Tagging to ask a question: Is it possible to improove error reporting for bundles? It's hard to guess what actually went wrong in such cases.

1 Like
541

What version of HE are you on? If it keeps being a problem you could open up the zip file and import each source file manually.