I’m running shelly binding quite a while and it was always smooth and worked like a charm <<<== thanks for all involved.
But (as there is always a but) I now got in trouble running openHAB 3.1.0 snapshot which causes issues with my shellybulb while Shellyplug seems to work without issues.
I can manage bulbs with binding but log is being floated with warnings
> 18:49:21.100 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyLightHandler of thing shelly:shellybulbduo:xxxx tried checking if channel meter#lastPower1 is linked although the handler was already disposed.
> 18:49:21.100 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyLightHandler of thing shelly:shellybulbduo:xxxx tried checking if channel meter#lastUpdate is linked although the handler was already disposed.
> 18:49:21.100 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyLightHandler of thing shelly:shellybulbduo:xxxx tried checking if channel device#heartBeat is linked although the handler was already disposed.
> 18:49:21.100 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyLightHandler of thing shelly:shellybulbduo:xxxx tried checking if channel device#uptime is linked although the handler was already disposed.
> 18:49:21.100 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyLightHandler of thing shelly:shellybulbduo:xxxx tried checking if channel device#wifiSignal is linked although the handler was already disposed.
> 18:49:21.115 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyLightHandler of thing shelly:shellybulbduo:xxxx tried checking if channel device#updateAvailable is linked although the handler was already disposed.
> > >
> 18:49:21.803 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyLightHandler of thing shelly:shellybulbduo:yyyy tried checking if channel device#heartBeat is linked although the handler was already disposed.
> 18:49:21.809 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyLightHandler of thing shelly:shellybulbduo:yyyy tried checking if channel device#deviceName is linked although the handler was already disposed.
> 18:49:21.928 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyLightHandler of thing shelly:shellybulbduo:yyyy tried checking if channel control#power is linked although the handler was already disposed.
> 18:49:21.928 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyLightHandler of thing shelly:shellybulbduo:yyyy tried checking if channel control#autoOn is linked although the handler was already disposed.
> 18:49:21.928 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyLightHandler of thing shelly:shellybulbduo:yyyy tried checking if channel control#autoOff is linked although the handler was already disposed.
> 18:49:21.928 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyLightHandler of thing shelly:shellybulbduo:yyyy tried checking if channel white#temperature is linked although the handler was already disposed.
> 18:49:21.928 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyLightHandler of thing shelly:shellybulbduo:yyyy tried checking if channel white#hsb is linked although the handler was already disposed.
> 18:49:21.928 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyLightHandler of thing shelly:shellybulbduo:yyyy tried checking if channel device#uptime is linked although the handler was already disposed.
> 18:49:21.928 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyLightHandler of thing shelly:shellybulbduo:yyyy tried checking if channel device#wifiSignal is linked although the handler was already disposed.
> 18:49:21.928 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyLightHandler of thing shelly:shellybulbduo:yyyy tried checking if channel device#updateAvailable is linked although the handler was already disposed.
> 18:49:21.928 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyLightHandler of thing shelly:shellybulbduo:yyyy tried checking if channel meter#currentWatts is linked although the handler was already disposed.
> 18:49:21.928 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyLightHandler of thing shelly:shellybulbduo:yyyy tried checking if channel meter#totalKWH is linked although the handler was already disposed.
> 18:49:21.928 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyLightHandler of thing shelly:shellybulbduo:yyyy tried checking if channel meter#lastPower1 is linked although the handler was already disposed.
> 18:49:21.928 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyLightHandler of thing shelly:shellybulbduo:yyyy tried checking if channel meter#lastUpdate is linked although the handler was already disposed.
> 18:49:21.928 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyLightHandler of thing shelly:shellybulbduo:yyyy tried checking if channel device#heartBeat is linked although the handler was already disposed.
> 18:49:21.928 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyLightHandler of thing shelly:shellybulbduo:yyyy tried checking if channel device#uptime is linked although the handler was already disposed.
> 18:49:21.928 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyLightHandler of thing shelly:shellybulbduo:yyyy tried checking if channel device#wifiSignal is linked although the handler was already disposed.
> 18:49:21.928 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyLightHandler of thing shelly:shellybulbduo:yyyy tried checking if channel device#updateAvailable is linked although the handler was already disposed.
Does anyone else expirience same and is there probably already a fix for it?
One important tip: MAKE SURE you define the item as an item type Number and NOT Number:Power or so as the latter adds unit characters to the output which makes something that cannot be processed easily. Also note that it is necessary to assign the state to a variable first to allow the comparison as a number (otherwise it will try compare strings which is probably a bug - see my other thread on that).
Hope this helps,
Stefan
PS: for the curious: the checkPowerActive flag avoids switching on with no power to directly being switched off again (kind of a hysteresis approach)
has anyone written any rules to calculate the accumulated power consumption measured by a Shelly 3EM? I had a 3EM installed yesterday that measures the three phases of my heating system, and so far I have only created items for the three currentWatts channels, and also a “pseudo item”, which is used to sum up those three whenever one of them changes.
I would like to be able to tell how much powered (kWh) was consumed by all three phases since the start of the day, since the start of the month, and I’d also like to store monthly power consumption somehow.
I don’t think the Shelly report those values by themselves (only the accumulated power since the last restart?), and downloading the CSV file provided by the 3EM doesn’t seem like a good option either…
I would have hoped, you could reset the totalKWH parameter but I checked in the docs and it is only readable. So the only idea I have is to write a cron-triggered rule that triggers every midnight which saves the current value and takes the difference to last-saved value. If you want you can assign this to a virtual number item that allows you to have a chart on that (very easy in OH3).
I think that calculating the totalkWh “myself” or rather in openHAB would be a better approach (but I’m not sure). Using the 3EMs integrated totalkWh parameter has the problem that it will get reset to 0 whenever the device restarts, e.g. after firmware updates. So I can’t really use that to calculate anything(?).
So I guess calculating everything myself would prevent that problem, but I’m not sure. Also not sure how would go about calculating it in an openHAB rule.
It would have been better if the 3EM had an internal counter for the three phases and their total power consumption which does not get reset after reboot.
Create an item which will be the sum of the three 3EM totalKWH values. Everytime that sum-item changes, I will calculate the difference to its previous value (newValue - oldValue). If the difference is positive, I will add that difference to another item that stores total consumption in kWh,
If the difference is negative, that probably means that the 3EM has restarted or the counters were reset for whatever other reason. Instead of adding the difference of the old and the new sum to the counter item, I will instead just sum up the three totalKWH values and add that sum to my counter.
Not sure if that makes sense… I will try writing a rule and comparing the result to what the Shelly returns as consumption via the Cloud and via the CSV file that can be exported…
I was just about to write the same. Check all updates and sum the difference. If it is negative you lost probably a bit but that shouldn’t be a lot as I would the update to come in regularly. And reset every midnight.
I experience an issue with an Shelly i3 on openhab 2.5.11.
(I gave up using CoAP. It might be a nice protocol, but does not work for me or my network.)
I have some Shellys operational via the http interface. I’m fine with it and would like to use it for the i3 as well. Unfortunately the registration of the action URLs on the Shelly does not happen or fails.
I disabled CoIot events and enabled all other, see attached screenshots.
Are there any debugging options to identify the issue?
Thanks in advance,
Sven
I use OH3 (migration of 2.5) and have since days a strange behaviour with the shelly binding. After a restart of the binding, I can use the shelly devices again. The shelly binding beaks down between 12 – 24 h after a restart
First, I used shelly binding 3.0 (standard) and got following behaviour Openhab log
2021-01-24 21:41:43.585 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘shelly:shelly1:8caab54ba22b’ changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Das Gerät antwortet nicht und ist vermutlich nicht mehr verfügbar.
2021-01-24 21:41:44.598 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘shelly:shelly25-roller:483fda77144f’ changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Das Gerät antwortet nicht und ist vermutlich nicht mehr verfügbar.
2021-01-24 21:41:45.534 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘shelly:shelly25-roller:483fda77144f’ changed from OFFLINE (COMMUNICATION_ERROR): Das Gerät antwortet nicht und ist vermutlich nicht mehr verfügbar. to ONLINE
2021-01-24 21:41:46.760 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘shelly:shelly25-roller:b947d31129’ changed from OFFLINE (COMMUNICATION_ERROR): Das Gerät antwortet nicht und ist vermutlich nicht mehr verfügbar. to ONLINE
2021-01-24 21:41:47.684 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘shelly:shelly25-roller:40f520008eb5’ changed from OFFLINE (COMMUNICATION_ERROR): Das Gerät antwortet nicht und ist vermutlich nicht mehr verfügbar. to ONLINE
2021-01-24 21:41:50.301 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘shelly:shelly1:d32aa601b5’ changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Das Gerät antwortet nicht und ist vermutlich nicht mehr verfügbar.
2021-01-24 21:41:50.751 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘shelly:shelly1:e64b81536a’ changed from OFFLINE (COMMUNICATION_ERROR): Das Gerät antwortet nicht und ist vermutlich nicht mehr verfügbar. to ONLINE
2021-01-24 21:41:50.759 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘shelly:shelly1:8caab54ba22b’ changed from OFFLINE (COMMUNICATION_ERROR): Das Gerät antwortet nicht und ist vermutlich nicht mehr verfügbar. to ONLINE
2021-01-24 21:41:51.407 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘shelly:shelly25-roller:40f520008e5f’ changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Das Gerät antwortet nicht und ist vermutlich nicht mehr verfügbar.
2021-01-24 21:41:51.997 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘shelly:shelly25-roller:40f520008e5f’ changed from OFFLINE (COMMUNICATION_ERROR): Das Gerät antwortet nicht und ist vermutlich nicht mehr verfügbar. to ONLINE
Then I made an update to a newer shelly binding version 3.1 (3.1.0.202101212341 x org.openhab.binding.shelly)
Now I get following error messages
Openhab log
2021-01-26 22:31:11.669 [INFO ] [y.internal.handler.ShellyBaseHandler] - shelly1-84cca8a6b113: FEHLER: Der Befehl OFF für Kanal shelly:shelly1:e5a07ed930:relay#output kann nicht verarbeitet werden - Device unreachable or API Timeout ()
2021-01-26 22:31:27.675 [INFO ] [y.internal.handler.ShellyBaseHandler] - shelly1-84cca8a6b113: FEHLER: Der Befehl OFF für Kanal shelly:shelly1:e5a07ed930:relay#output kann nicht verarbeitet werden - Device unreachable or API Timeout ()
2021-01-26 22:31:42.690 [INFO ] [y.internal.handler.ShellyBaseHandler] - shelly1-84cca8a6b113: FEHLER: Der Befehl ON für Kanal shelly:shelly1:e5a07ed930:relay#output kann nicht verarbeitet werden - Device unreachable or API Timeout ()
2021-01-26 22:31:57.718 [INFO ] [y.internal.handler.ShellyBaseHandler] - shelly1-84cca8a6b113: FEHLER: Der Befehl OFF für Kanal shelly:shelly1:e5a07ed930:relay#output kann nicht verarbeitet werden - Device unreachable or API Timeout ()
2021-01-26 22:32:12.743 [INFO ] [y.internal.handler.ShellyBaseHandler] - shelly1-84cca8a6b113: FEHLER: Der Befehl OFF für Kanal shelly:shelly1:e5a07ed930:relay#output kann nicht verarbeitet werden - Device unreachable or API Timeout ()
2021-01-26 22:32:48.284 [INFO ] [y.internal.handler.ShellyBaseHandler] - shellyswitch25-40f520008eb5: FEHLER: Der Befehl DOWN für Kanal shelly:shelly25-roller:40f520008eb5:roller#control kann nicht verarbeitet werden - Device unreachable or API Timeout ()
2021-01-26 22:39:00.828 [INFO ] [y.internal.handler.ShellyBaseHandler] - shellyswitch25-40f520014eff: FEHLER: Der Befehl DOWN für Kanal shelly:shelly25-roller:40f520014eff:roller#control kann nicht verarbeitet werden - Device unreachable or API Timeout ()
2021-01-26 22:39:00.838 [INFO ] [y.internal.handler.ShellyBaseHandler] - shellyswitch25-483fda77144f: FEHLER: Der Befehl DOWN für Kanal shelly:shelly25-roller:483fda77144f:roller#control kann nicht verarbeitet werden - Device unreachable or API Timeout ()
2021-01-26 22:39:15.867 [INFO ] [y.internal.handler.ShellyBaseHandler] - shellyswitch25-483fda77144f: FEHLER: Der Befehl STOP für Kanal shelly:shelly25-roller:483fda77144f:roller#control kann nicht verarbeitet werden - Device unreachable or API Timeout ()
2021-01-26 22:39:17.501 [INFO ] [y.internal.handler.ShellyBaseHandler] - shellyswitch25-40f520014eff: FEHLER: Der Befehl STOP für Kanal shelly:shelly25-roller:40f520014eff:roller#control kann nicht verarbeitet werden - Device unreachable or API Timeout ()
2021-01-26 23:31:15.017 [INFO ] [y.internal.handler.ShellyBaseHandler] - shellyswitch25-40f520008eb5: FEHLER: Der Befehl DOWN für Kanal shelly:shelly25-roller:40f520008eb5:roller#control kann nicht verarbeitet werden - Device unreachable or API Timeout ()
Event log
2021-01-26 22:31:00.964 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘Burolicht_Betrieb’ changed from OFF to ON
2021-01-26 22:31:32.757 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘Burolicht_Betrieb’ received command OFF
2021-01-26 22:31:32.760 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘Burolicht_Betrieb’ predicted to become OFF
As said, everything works well for a time after a restart of the binding. the devices are reachable via the browser and I can use them with the browser.
edit the strange thing is that even if I cant steer the device the right state is shown everytime. So when I push the button it’s shown as active/inactive but actions/comannds won’t come thorugh openhab to the shelly devices. used are shelly 1 and shelly 2.5
what is the issue? why is CoAP not working?
fyi: I added a dispatch of inbound multicast packets based on the mac address in the CoIoT header if the source ip doesn‘t match. In a routed environment with a multicast proxy the source ip may get replaced with the interface ip of the router/proxy. The device id in the header stays valid. Use the latest DEV build for a teat
—
Latest DEV build: 2.5.12 - 3.1.0 - README - Installation - Bugs/Features - Firmware Index - Firmware Archive - API Doc
Note: The binding version included in the final OH 3.0 distro is significantly older than the DEV build. I can’t make it in-time. Make sure you deleted older versions of the binding when installing the 2.5.12-SNAPSHOT or 3.1.0-SNAPSHOT if you are already on OH 3.
I’m using 2.5.11 and it seems like the is no mapping for turning on or off a shelly duo; that corresponds to /light/0?turn={on|off} in the REST API. The command is useful because it allows to restore the same brightness level that was set when bulb was turned off.
Is this planned for future releases (for openhab2)?
Alternatively, is there a simple way to get around this limitation? I’m googling and it looks like invoking a REST API from openhab2 is much more complex than I imagined.
I’m annoyed by the hassle of testing CoAP in the past. I think it was Nov last year when I tried it the last time. It was about latest greatest Shelly firmwares and latest greatest dev build of Shelly bindings and so on, but it did no twork for me. Delays and totally missing reactions. So I banned this approach for me. The time has not come yet I’m willing to give it another chance.
I don’t like using multicast for my smart home. I don’t want to distribute related information to my whole network. I prefer dedicated TCP connection such as used by HTTP or MQTT. I don’t say I’m not using muticast. I like the convenience of Bonjour to discover services in the network. I used multicast in various IT projects and in all of them it was a hassle and error prone.
Long story short: CoAP/CoIoT and myself, we don’t come together.
Simply no. I won’t, sorry.
Coming back to my original question
Is it still suppported by the binding?
If not, this is ok. My solution would be to switch over to MQTT.
Hi Markus
After Update to the newest DEV-Version on Openhab 3.0.1 (before the 3.0-DEV-Version) all Shellys are again in INBOX. What can I do?
Thanks for the great binding and your help.
I will try writing a rule and comparing the result to what the Shelly returns as consumption via the Cloud and via the CSV file that can be exported…
