That means that “That means that even though I have configured everything correctly” is not correct. Discover the device, press the device button, thing gets ONLINE and creates channels. I don’t know where’s the problem. For example the Z-Wave binding works the exact same way.
I don’t know if this works, but the alarm channel is a trigger channel.
You could catch this in a rule with “Channel ‘shelly:xxx:device#alarm’ triggered xxx”
That’s not the way it should wok. Once a device is initialized (in case of the PlusSmoke via WebSocket event) it connects back to OH and sends a sensor update a) when something changed b) after a certain interval (I think 720min). Please do testing and provide DEBUG logs if this doesn’t work.
I agree with you that if it’s necessary to set up a connection (e.g. for plus devices) the device has to come online at least once.
But it seems to already have that connection because it properly reports the battery level to openhab (see post above).
That means the connection from the plus device to openHAB is already working.
It feels (no proof) that there are many things that can go wrong during auto discovery and creation of thing channels which then leaves the device in a pending state.
Since that results in a useless device I’m looking for a manual way to configure the device so the auto discovery and creation of channels is not necessary.
For the normal shellys I’ve already set up CoIoT to a fixed ip adress so no interaction of the binding should be necessary.
What would be the outgoing websocket configuration for the plus devices?
No - there are some fundamental differences:
All the z-wave devices will work immediately after an openHAB restart - even the battery powered onces.
Additionally it’s possible to configure the z-wave things manually:
Thing zwave:intermatic_ha01c_00_000:controller:node4 "Switch" (zwave:serial_zsk:controller) [ node_id=4 ]
That way it’s not necessary to do any device discovery and dynamic channel creation because the intermatic_ha01c_00_000 exactly describes what kind of device that is and what kind of channels it has.
We already have the channel description in the binding docs - so why not add more things statically (like the device#alarm and device#wifiSignal). If I configure a shelly25-roller it obviously needs the rollershutter channel.
My main issue is that every restart of openHAB and every shelly thing change becomes a gamble.
How long will my battery powered devices remain in pending state and all my rules not work because of the missing channels? Will this time the discovery of mains powered devices work correctly (which seems to work most of the time but not always)?
The solution can’t be to manually wake every battery powered device e.g. after an openHAB restart.
Some devices are screwed closed and distributed all over the house in not easily reachable places e.g. have a flood sensors hidden under the cabinets in the kitchen.
If it’s really necessary to manually wake every battery powered device after a restart something is fundamentally broken with the binding and there needs to be a different way to do things.
indeed it works like that, at least in my enviroment (i configured them file-based). i supppose it is useless to capture a debug log because the (sometimes) big time gaps are not a bug in the binding but by design of the shelly sensors.
i wrote a rule with a ‘watchdog’ that checks regularly if shellys wake up and send their alive signal. i noted how long the longest time gaps are: sensor hwr took once 12 days for the next message, sensor wohnzimmer took 22 days and schlafzimmer even once was 24 days time gap. not always, i see often they are updated dayli but sometimes it takes that long. of course, if i press the test button they update immediately. here a screenshot of my sitemap, you see, hwr again has not reported since 10 days:
smoke sensors are security relevant and i think they should not stay pending if initialized once and working. think about a power outtake, or just a normal user reboot. even if they would update every 12 hours there is much time a possible fire alarm would not be processed.
Ok, there is no way to wake of Shelly battery devices from remote, no matter if it is Gen1 or Gen2. That’'s a technical design decision made by them to get long battery lifetimes, but the sensor has to wake up every 12h by itself or when sensor data changed. If not, there is a bug in the sensor or in the binding. Therefore: Yes, a log makes sense, even it is log. At the end grep helps to filter (e.g. you could search for the thing id, which prefixes almost all debug log entries), e.g. in parallel with a Wireshark to see if the device sends a packet and the binding doesn’t show it = binding bug, or the device doesn’t send an update = firmware bug.
ok, i actually use binding version 4.0.0.202307172029
hopefully i understand correct, i set in karaf:
log:set DEBUG org.openhab.binding.shelly
and now i watch events.log for entries and will report after some capturing time.
till now log level was set to info and i see in this log something like:
2023-08-13 20:28:57.320 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'shelly:shellyplussmoke:80646FD12F7C' changed from UNKNOWN (CONFIGURATION_PENDING): Initialisierung oder Gerät im Schlafmodus. to ONLINE
2023-08-13 20:28:57.345 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'iShSmoke_Schlafzimmer_TS' changed from 2023-08-11T20:01:33.000+0200 to 2023-08-13T20:28:57.000+0200
2023-08-13 20:28:57.397 [INFO ] [openhab.event.InboxAddedEvent ] - Discovery Result with UID 'shelly:shellyplussmoke:80646fd12f7c' has been added.
2023-08-13 20:28:58.679 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'shelly:shellyplussmoke:80646FD12F7C' changed from ONLINE to UNKNOWN (CONFIGURATION_PENDING): Initialisierung oder Gerät im Schlafmodus.
2023-08-13 20:28:58.881 [INFO ] [openhab.event.ChannelTriggeredEvent ] - shelly:shellyplussmoke:80646FD12F7C:device#alarm triggered UNDEFINED
2023-08-13 20:28:58.889 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'iShSmoke_Schlafzimmer_TS' changed from 2023-08-13T20:28:57.000+0200 to 2023-08-13T20:28:58.000+0200
2023-08-13 20:28:58.927 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'shelly:shellyplussmoke:80646FD12F7C' changed from UNKNOWN (CONFIGURATION_PENDING): Initialisierung oder Gerät im Schlafmodus. to ONLINE
and
2023-08-14 20:40:34.557 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'shelly:shellyplussmoke:80646FD12F7C' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Das Gerät antwortet nicht und scheint nicht mehr verfügbar zu sein.
No, openhab.log
Hi Guys i have installed an Shelly Motion 2, so far everything is working except the battery charger status. It says 100% but the Battery is not green:
Has someone an idea?
Regards
Simon
Are you using dynamic icons? If yes, what are their names? I assume that you are storing a value between 0 and 1, wheras your icon, (if dynamic icons), react on values between 0 and 100.
thats a good question, i only created the displayed item and display that in the sitemap.
Text label="Smarte Geräte" {
Text item=Bewegungsmelder_Batterieladung label="Ikea Bewegungsmelder"
Text item=Shelly_Motion_Batterieladung label="Shelly Bewegungsmelder"
if i check the item on the “item” list it shows 1
…and the ikea item shows 87, I assume.
Either create a profile which converts your decimal to an integer or create your own dynamic icon set.
yes i compared the devices and i changed Type
type: Number:Dimensionless to Number
and actually it shows 1.
and i see an questionmark
Hello
Simple question for me: I have a lot of shellies, and all of them work fine over MQTT.
I am currently switching from Openhab 2.5 (in dedicated LXC) to v4 (in docker). Decided to use this plugin instead of MQTT.
All shellies work fine, except the 2 HT that I have. They still report over MQTT, so I know they work. But can’t get them report in the plugin besides first sync. Probably setup issue. I have this log below which may explain, if not, will provide mode logs.
2023-08-08 01:01:05.358 [INFO ] [nternal.manager.ShellyManagerServlet] - Shelly Manager started at http(s)://192.168.48.1:8081/shelly/manager
2023-08-08 01:01:06.906 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'shelly:shellyix3:98cdac307926' to inbox.
2023-08-08 11:54:05.473 [INFO ] [y.internal.handler.ShellyBaseHandler] - shellyem-b16445: CoIoT peer updated to 192.168.48.1:5683
2023-08-08 13:51:54.471 [INFO ] [nternal.manager.ShellyManagerServlet] - Shelly Manager started at http(s)://192.168.48.1:8081/shelly/manager
2023-08-09 21:23:41.215 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'shelly:shellyplugs:b85d12' to inbox.
2023-08-09 21:23:41.473 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'shelly:shellyem:d3b3d6' to inbox.
2023-08-09 23:07:59.962 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'shelly:shellytrv:60a423d0e10a' to inbox.
2023-08-09 23:08:28.710 [INFO ] [y.internal.handler.ShellyBaseHandler] - shellytrv-60a423d0e10a: CoIoT peer updated to 192.168.48.1:5683
2023-08-11 18:18:47.698 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'shelly:shellyem:d3b3d6' to inbox.
2023-08-12 09:23:56.894 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'shelly:shellyem:b16445' to inbox.
2023-08-14 18:05:23.443 [INFO ] [y.internal.handler.ShellyBaseHandler] - shellyht-caad554c6d: CoIoT peer updated to 192.168.48.1:5683
2023-08-14 18:12:40.460 [INFO ] [y.internal.handler.ShellyBaseHandler] - shellyht-ec25ad1466: CoIoT peer updated to 192.168.48.1:5683
thanks for any advice you can provide.
I am not familiar with ht device. If it is a Gen 1 device, check the CoIoT settings of your device. What does it say?
Did you wake up your device and try to add it then?
it is added, and visible in the shelly manager.
Not sure how to see additional CoIoT settings in addition to what is at the end of the log already.
I see update time of 43260s in the shelly manager, in comparison to TRV which has update time to 7210s.
But my assumption is that when device wakes up based on Temp/Hum trheashold change, then it also updates values over CoIoT. TRV does this fine.
It is on your device. Go to Internet settings → developer settings
yes, CoIOT enabled, with remote address set to 192.168.48.1:5683.
not sure what this address means though. but it is the same as TRV, which reports temperature fine.
EDIT: seems I forgot to tick Enable Sensor Events on the Thing page. Working better now. Sorry about this.
If you enable it and provide the port number, it communicates in unicast mode to your openhab server instead of sending out multicast.
But that sounds that the binding correctly integrates your ht device.
Can you disable MQTT in your device? Maybe it justs establishes one connection either via MQTT or CoIoT.
You should not need to enable the events in the thing settings. That‘s the fallback mode when Coap can‘t be used.
If you are running OH in a docker container you need to make sure that UDP:5683 gets routed into the container. Is 192.168.48.1 the correct OH interface address connected to WiFi and is the HT (yes Gen1) connected to the same network?
„192.168.48.1:5683.not sure what this“ this should be your OH interface IP, Port 5683 for the Coap protocol.
you could enable debugging
Also read the info on network settings in the doc/advanced user doc
Hi,
I bought shelly ht and smoke devices. I could setup the HT with thing and item files, I can see it in shelly manager, and data in database, but for smoke I got the following:
No ThingHandlerFactory found for thing shelly:shellyplussmoke:smoke-konyha (thing-type is shelly:shellyplussmoke). Deferring initialization.
My things file:
Thing shelly:shellyht:temp01 [ deviceIp="temp01", userId="", password="", lowBattery=15, eventsCoIoT=true ]
Thing shelly:shellyplussmoke:smoke01 [ deviceIp="smoke01", userId="", password="", lowBattery=15 ]
Thing shelly:shellyplussmoke:smoke02 [ deviceIp="smoke02", userId="", password="", lowBattery=15 ]
openhab version is 3.4.3
What did I miss here?
Thanks