Shelly Device Handlers for Hubitat

The Driver is for Shelly 3EM 3Phase power meter? If so can't seem to get it to work. It connects to the device bot no power metering options.... any ideas?

This driver currently has no Pro 3 EM support.
It you could send me driver logs, I could try to add.

I can try to add using official documentation. Log will help to check events/notifications with real device behavior.

Enable description logging to see extensive device logs. If will start to dump all device responses.

Also, driver should show detected components list in the device data section down below. Would be helpfull to see that list.

P.S.:

To be clear
Shelly 3EM and Shelly Pro 3EM are two different devices of different protocol generations. There is no way to add the first one except writing a completely new driver. While the second one can be added.

Kk I'll set everything up and provide the data

I updated driver with Pro 3 EM code in the repo. But I cannot test it. So I assume by default that there are issues :upside_down_face:

Driver should spawn 4 child devices: Phase A, Phase B, Phase C and Total. For now I did not exposed aparent power and returned energy readings. Also neutral wire current value is not exposed.

To properly spawn child devices:
0. Enable debug logging to see all the request and responses in the device log

  1. Set IP and save settings
  2. Press 'Configure'.

'Configure' clears all previous child devices, polls device for all the componets and their instance counts, spawns child devices according to the fetched info, opens web socket connection and sends status request over it to start getting device notifications.

Ideally there should be no errors :hand_with_index_finger_and_thumb_crossed:
If by chance everything will work as you expect, you may disable debug logging.

1 Like

Ok I removed the device and added it anew. I dont think it connects properly

I get an error importing the driver code

Logs

You picked only a single file. Driver uses libraries and custom generic component devices (due to the lack of needed capabilities in the builtin generic driver set).

You either need to install libraries listed at the driver code top, or simply take the whole bundle (as a single operation). Taking bundle is simpler: go to the bundle tab on the left; there will be import button that will ask you for a ZIP file. ZIP-file contains all the dependencies inside.

Bundle can be downloaded from repo and uploaded. Or it can be uploaded directly from repo URL copying link from

If you want to install driver manually, then you will need 4 child device drivers and 3 library files.

2 Likes

Ok connected to the device,

No child devices present. We have readings. Im still waiting for my solar plant so the sensors aren't attached... but that's no problem I believe... no child devices

2023-04-28 23:13:13.961info(null) Meter generic report: Electric:voltage - 234.2V

dev:322023-04-28 23:13:13.960info(null) Meter generic report: Electric:voltage - 0.1V

dev:322023-04-28 23:13:13.958info(null) Meter generic report: Electric:voltage - 0.1V

dev:322023-04-28 23:13:13.957info(null) Phase C power factor 1.00

dev:322023-04-28 23:13:13.955info(null) Phase B power factor 1.00

dev:322023-04-28 23:13:13.954info(null) Phase A power factor 1.00

dev:322023-04-28 23:13:13.952info(null) Meter generic report: Electric:amperage - 0.082A

dev:322023-04-28 23:13:13.951info(null) Meter generic report: Electric:amperage - 0.027A

dev:322023-04-28 23:13:13.949info(null) Meter generic report: Electric:amperage - 0.027A

dev:322023-04-28 23:13:13.948info(null) Meter generic report: Electric:amperage - 0.028A

dev:322023-04-28 23:13:13.946info(null) Meter generic report: Electric:power - -0.135W

dev:322023-04-28 23:13:13.945info(null) Meter generic report: Electric:power - -0.1W

dev:322023-04-28 23:13:13.943info(null) Meter generic report: Electric:power - 0.0W

dev:322023-04-28 23:13:13.942info(null) Meter generic report: Electric:power - 0.0W

dev:322023-04-28 23:13:13.939info(null) parseShellyEnergyMeterStatus [a_act_power:0.0, b_aprt_power:0.0, b_act_power:0.0, total_current:0.082, n_current:null, total_act_power:-0.135, a_voltage:0.1, c_current:0.027, b_current:0.027, a_current:0.028, b_voltage:0.1, a_aprt_power:0.0, c_voltage:234.2, a_pf:1.00, c_aprt_power:6.2, total_aprt_power:6.241, id:0, c_pf:1.00, b_pf:1.00, c_act_power:-0.1]

dev:322023-04-28 23:13:10.959info(null) Meter generic report: Electric:voltage - 234.2V

dev:322023-04-28 23:13:10.957info(null) Meter generic report: Electric:voltage - 0.1V

dev:322023-04-28 23:13:10.956info(null) Meter generic report: Electric:voltage - 0.1V

dev:322023-04-28 23:13:10.954info(null) Phase C power factor 1.00

dev:322023-04-28 23:13:10.953info(null) Phase B power factor 1.00

dev:322023-04-28 23:13:10.951info(null) Phase A power factor 1.00

dev:322023-04-28 23:13:10.950info(null) Meter generic report: Electric:amperage - 0.083A

dev:322023-04-28 23:13:10.948info(null) Meter generic report: Electric:amperage - 0.028A

dev:322023-04-28 23:13:10.947info(null) Meter generic report: Electric:amperage - 0.027A

dev:322023-04-28 23:13:10.945info(null) Meter generic report: Electric:amperage - 0.028A

dev:322023-04-28 23:13:10.944info(null) Meter generic report: Electric:power - -0.05W

dev:322023-04-28 23:13:10.942info(null) Meter generic report: Electric:power - 0.0W

dev:322023-04-28 23:13:10.941info(null) Meter generic report: Electric:power - 0.0W

dev:322023-04-28 23:13:10.939info(null) Meter generic report: Electric:power - 0.0W

dev:322023-04-28 23:13:10.937info(null) parseShellyEnergyMeterStatus [a_act_power:0.0, b_aprt_power:0.0, b_act_power:0.0, total_current:0.083, n_current:null, total_act_power:-0.050, a_voltage:0.1, c_current:0.028, b_current:0.027, a_current:0.028, b_voltage:0.1, a_aprt_power:0.0, c_voltage:234.2, a_pf:1.00, c_aprt_power:6.5, total_aprt_power:6.477, id:0, c_pf:1.00, b_pf:1.00, c_act_power:0.0]

I will investigate tomorrow.
Good news is that WS stream is live. Device sends reports as expected. Component names turned to be correct. The issue is strictly in missing child devices (to which to put these readings).

Would be helpfull to see log of "Configue" operation (when button is pressed). There could be some usefull error.
And component list from the bottom of the driver (to see how exactly EM and EMData components were detected)

1 Like

No problem everything You need to get this going.

Logs spat few errors

dev:322023-04-29 08:04:35.135info(null) parseShellyEnergyMeterStatus [a_act_power:0.0, b_aprt_power:0.0, b_act_power:0.0, total_current:0.081, n_current:null, total_act_power:-0.185, a_voltage:0.1, c_current:0.027, b_current:0.027, a_current:0.028, b_voltage:0.1, a_aprt_power:0.0, c_voltage:234.5, a_pf:1.00, c_aprt_power:6.3, total_aprt_power:6.258, id:0, c_pf:1.00, b_pf:1.00, c_act_power:-0.2]

dev:322023-04-29 08:04:34.464infoDevice updates [:]

dev:322023-04-29 08:04:33.206errorCan't get device status for null: Bad Request

dev:322023-04-29 08:04:33.195infoparseShellyCloudStatus [connected:true]

dev:322023-04-29 08:04:33.192errorjava.lang.NullPointerException: Cannot get property 'value' on null object on line 895 (method parse)

dev:322023-04-29 08:04:33.170infoparseShellyCloudStatus [connected:true]

dev:322023-04-29 08:04:33.122errorjava.lang.NullPointerException: Cannot get property 'value' on null object on line 890 (method parse)

dev:322023-04-29 08:04:33.050errorjava.lang.NullPointerException: Cannot get property 'value' on null object on line 895 (method parse)

dev:322023-04-29 08:04:33.038errorjava.lang.NullPointerException: Cannot get property 'value' on null object on line 890 (method parse)

dev:322023-04-29 08:04:32.980infoWS query: {"params":{id:0}, "id":40, "method":"EMData.GetStatus", "src":"hub"}

dev:322023-04-29 08:04:32.958infoWS query: {"params":{id:0}, "id":30, "method":"EM.GetStatus", "src":"hub"}

dev:322023-04-29 08:04:32.940infoHTTP query: Wifi.GetStatus([:])

dev:322023-04-29 08:04:32.925infoHTTP query: Shelly.CheckForUpdate([:])

dev:322023-04-29 08:04:32.909infoHTTP query: Cloud.GetStatus([:])

dev:322023-04-29 08:04:32.869infoWS query: {"params":{id:0}, "id":40, "method":"EMData.GetStatus", "src":"hub"}

dev:322023-04-29 08:04:32.859infoWS query: {"params":{id:0}, "id":30, "method":"EM.GetStatus", "src":"hub"}

dev:322023-04-29 08:04:32.851infoHTTP query: Wifi.GetStatus([:])

dev:322023-04-29 08:04:32.847infoHTTP query: Shelly.CheckForUpdate([:])

dev:322023-04-29 08:04:32.841infoHTTP query: Cloud.GetStatus([:])

dev:322023-04-29 08:04:32.828errorconfigure: No signature of method: user_driver_drozovyk_Shelly_Plus_Pro_xPM_591.getMeterDevice() is applicable for argument types: (java.lang.Short) values: [1]
Possible solutions: getMeterDevices(java.lang.Short), getCoverDevice(java.lang.Short), getInputDevice(java.lang.Short), getMeterDeviceName(java.lang.Short, int), getSwitchDevice(java.lang.Short). Can't configure child devices. Please, re-try.

Device details

1 Like

I updated the driver with fixes. Just reimport the bundle (no need to reinstall device itself)

Configured device should look now somethin like this

Thanks to your logs I was able to emulate device notifications locally. Also I added powerFactor attribute to the child defices.

Readings that are currently not supplied to any attribute are 'aparent power' and ' returned energy'. Also per-channel error are not reported. These can be added later taking into account desired use case scenario.

Also atm there were no notifications regarding energy (as according to the device documentation such notification should arrive when device stores accumulated energy readings in the internal memory).

1 Like

I'll try to test it today. Hope it works😃

Ok looks good

Although I got a warning

I suspect this might be caused by the device notification frequency. Should be configurable on the device itself (notification interval and notification threshold.. something like that)

Event history? Nothing else seems to influence reporting

No. Not in the driver but on the device itself.

Nothing like that sadly


Try to check event history to identify what specific events were spammed. It shows mainly Phase-C channel. So it might be related to some line activity.

In general my Pro2PM sends notifications once a minute. Events are not trigerred because values mostly remain unchanged. ECO mode has no effect on this.

Actually might be a good idea to contact Shelly to get more info on this.

I will try to change ping interval for websocket connection in case it might have some relation.
(Update: no effect from pingInterval change, so it's completely on device side)

1 Like

The sensors aren't atached maybe that's cosing the traffic.

Not sure if traffic is caused by missing sensors. But rather values might fluctuate due to this reason. And fluctuating values may be the reason of atribbute change events.

Anyway looking at event history you can see what specific attributes are constantly changing.

1 Like

Small announcement :slightly_smiling_face:: I'm experimenting with Shelly script component. Somewhere closer to the upcoming weekend I'm planning to update my driver with this feature.

If device has configured scripts, driver will spawn new child devices accordingly. Each such device has commands to start/stop/refresh corresponding script (attribute for the current status). And attribute for the arbitrary data, sent from script to hub. This attribute is from 'Variable' device capability. Any Hubitat app that can work with 'variables' can benefit from it.

Script sample (JavaScript on the Pro2PM) and generated trafic:

let alertTimer = null;

function startTimer() {
  let timeStep = 10* 1000; // 10S
  alertTimer = Timer.set(timeStep, true, function (ud) {
    Shelly.emitEvent("ping", "ping_event_data");
  }, null );
}

startTimer()

info(Shelly Pro 2PM Test script 1) Script event [component:script:1, data:ping_event_data, id:1, event:ping, ts:1683132133.01]
info(Shelly Pro 2PM Test script 1) Script event [component:script:1, data:ping_event_data, id:1, event:ping, ts:1683132123.01]

Example use case: It is possible to filter power/energy reports by the shelly device schedule to emulate reporting of the electricity for multizone tariff.

In fact the absolute majority of such logic can be made with RM. Just a way to distribute computational load if such solutions looks more convinient.

Driver is updated:
Added Shelly digest authentification support
Added script support