Shelly Binding

When I set the loglevel to DEBUG, it throws a lot of lines into the log, none of which look Shelly-related. I also don’t want to post a unredacted log either here or in Github, so can you tell me what I should filter for?

This is the log at INFO level, btw:

15:36:12.199 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_state' changed from stop to open     //pushing the up-button
15:36:12.204 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_currentpower' changed from 0 W to 104.84 W
15:36:14.872 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_position' changed from 100 to 0      // this is the position from the Shelly binding
15:36:14.880 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_currentpower' changed from 104.84 W to 104.49 W
15:36:27.218 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_position' changed from 0 to 100      // position from binding again
15:36:27.225 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_currentpower' changed from 104.49 W to 106.29 W
15:36:27.790 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_ShutterActualPos' changed from 0 to 100   // this is the position from MQTT
15:36:28.008 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_position' changed from 100 to 0      // position from binding again
15:36:28.009 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_state' changed from open to stop
15:36:28.012 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_currentpower' changed from 106.29 W to 0 W   // shutter has come to a stop
15:36:43.588 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_state' changed from stop to close            // pushing the down-button
15:36:43.594 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_currentpower' changed from 0 W to 106.08 W
15:36:45.283 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_position' changed from 0 to 100              // position from binding
15:36:45.286 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_currentpower' changed from 106.08 W to 106.06 W
15:36:48.360 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_currentpower' changed from 106.06 W to 107.4 W
15:36:58.585 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_position' changed from 100 to 0              // position from binding again
15:36:58.590 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_currentpower' changed from 107.4 W to 45.59 W
15:36:58.783 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_ShutterActualPos' changed from 100 to 0      // position from MQTT
15:36:59.149 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_position' changed from 0 to 100              // position from binding again
15:36:59.152 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_state' changed from close to stop
15:36:59.158 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_currentpower' changed from 45.59 W to 0 W
15:37:00.409 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'studyshutter_totalenergy' changed from 0.035 kWh to 0.036 kWh

Are you using the latest DEV build?
you can send me a PM, but I need a detailed log

I’m running 4.0.0 M1. I’ve sent you the debug log in a PM.

Just tested with my productive system: The problem has improved as now the third press gets recognized as SHORT_PRESSED event. Besides updating the binding, I also set a keep-alive of 2s for all my shellies - maybe this also has something to do with it.

I will do another test with a testing environment in the next days to see, if this is a problem of my prod environment, network, … or if it has something to do with the binding.

Nevertheless, this is a huge improvement compared to before your fixes. Again thanks for your help and your work, really appreciate that :+1:

You should see the event already on the first click

On the first click, I only see the Thing state changing from UNKNOWN to ONLINE - but no event.

<edit>
Just to preempt the question about recent binding version:

> sha256sum org.openhab.binding.shelly-3.4.3-SNAPSHOT.jar 
305efe0a09d6611d361647c326e8a0f250293ee6d99a0352a308bc396428760b  org.openhab.binding.shelly-3.4.3-SNAPSHOT.jar

> curl --silent --location "https://github.com/markus7017/myfiles/blob/master/shelly/org.openhab.binding.shelly-3.4.3-SNAPSHOT.jar?raw=true" | sha256sum 
305efe0a09d6611d361647c326e8a0f250293ee6d99a0352a308bc396428760b  -

</edit>

EDIT: I missed the comment with another update where you fixed an issue apparently. Will try again tomorrow so feel free to ignore the remaining post :wink:

Resetting totals still does not seem to work for me.

After setting DEBUG for the binding the only output is:

2023-03-27 23:39:12.962 [DEBUG] [.internal.handler.ShellyRelayHandler] - shellyem3-3494547b8d5f: Reset Meter Totals
2023-03-27 23:39:13.046 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shellyem3-3494547b8d5f: Channel meter1#resetTotals updated with OFF (type class org.openhab.core.library.types.OnOffType).

But no change in the totalKWH or returnedKWH values.

As the DEBUG log didn’t tell me the exact API call I’m still not sure why it does not work.

Using cURL I could reset the counters via:

curl -XGET http://IP/emeter/2?reset_totals=true

hmm, is it =true or =1?
just uploaded a build with =true

total needs to be. cleared in the device, the status update will then recompute totalKWH

a TRACE log will show the called URL

The API docs say Type=any :wink:
So for me it worked with =true, while just adding ?reset_totals without any value did nothing.

@markus7017 with the latest build and TRACE I find:

HTTP GET for http://192.168.246.101/emeter/0/reset_totals=1

Bundle version: org.openhab.binding.shelly:3.4.3.202303280624

BUT I didn’t restart openhab but only did a bundle:stop and bundle:start.

So if the above is the expected API call it’s not correct because reset_totals is a parameter and not a resource. So the ? is missing.

that should be fixed already, let me check the back port from v4 to v3

EDIT:
you are right, my script to back port code from v4 to v3 didn’t worked properly. Please try the updated build

With the latest build it is working! Thanks!

hi,i got today a Shelly Plus Plug S and the binding discovered it but says its unsupported device…I that correct?Can i mannually add it?

you beed to update to the latest DEV build, see REaDMEBeta

3.4.3-DEV Gen1/Plus/Pro | 4.0.0-DEV Gen1/Plus/Pro | README | READMEbeta
Avdanced Users - Shelly Manager - Bugs/Features - API Doc | Firmware Index - Firmware Archive

Note: The DEV build is always newer than the version in the official Distro or Milestone builds

if you do it right, it works :slight_smile:

1 Like

Thnx,I got it working yesterday,I found instructions at marketplace binding…thank you.

Hello,
I have 4 Shelly H&T

  • 2 are powered through USB-C and are working fine in OpenHAB
  • 2 are running with batteries and are never sending any data to OpenHAB

They are all configured in the exact same way in .things and .items files.
And are all working fine in Shelly app of course.

So : is it possible to have these “battery powered devices” working in openhab ? What is the principle, is openhab constantly trying to reach them (so they have to be connected / sending something, in order for the openhab > shelly devices connection to be possible ? (hence why it’s not working : mismatch of polling / availability between the two))

Yes, having 5 of them runninge over here.

No, battery operated devices have to push their state updates to openHAB. Polling updates does not really work, as those devices are in sleep mode most of the time. They just wake up when values have changed.
If you power them via USB, openHAB is also using the backup polling task.

What is the state reported in shelly manger ? When was the last update seen?
Did you configure Coap/CoIoT correct ?

In shellymanager, right now i see only 3 out of 4

No i don’t know about Coap/CoIoT, never configured that, i’ll check that point, it’s probably what is missing right now, thanks.

I updated the DEV build

  • Pro 3EM: total_xxx values are taking from device (e.g. channel totalKWH) rather than aggregated from single phaases.
  • EM/3EM: totalReturned reported kw instead of kw/h, I added a “/ 60” to make it kw/h

4.0 beta users might need to upgrade to the latest 4.0.0-SNAPSHOT, the team updated some of the core components


3.4.3-DEV Gen1/Plus/Pro | 4.0.0-DEV Gen1/Plus/Pro | README | READMEbeta
Avdanced Users - Shelly Manager - Bugs/Features - API Doc | Firmware Index - Firmware Archive


Note: The DEV build is always newer than the version in the official Distro or Milestone builds