Thanks, this is working now
hi @markus7017,
I’ve looked around and did not find anything specific, so posting here:
ShellyPlugS running 20230803-125306/1.0.0-gaec0744
Openhab 4.0.1
279 │ Active │ 80 │ 2.7.4 │ Californium (Cf) Core
280 │ Active │ 80 │ 2.7.4 │ Californium (Cf) Element Connector
281 │ Active │ 80 │ 2.7.4 │ Californium (Cf) OSGi
28 │ Active │ 80 │ 4.0.0.202307211506 │ openHAB Add-ons :: Bundles :: Shelly Binding Gen1+2
Running OH in Docker Swarm, so using NGINX reverse proxy for same reasons as someone mentioned above with Traefik.
Added plug item and status ends up being:
Status:UNKNOWN
CONFIGURATION_PENDING
Initializing or device in sleep mode.
Checking logs, I can see this:
openhab> log:tail org.openhab.binding.shelly
16:08:36.104 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellyplugs-8c3b28cc45: Stopping Thing
16:08:36.105 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellyplugs-8c3b28cc45: Shutting down
16:08:36.107 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellyplugs-8c3b28cc45: Shelly statusJob stopped
16:08:36.120 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellyplugs-8c3b28cc45: Shutting down
16:08:37.142 [DEBUG] [.shelly.internal.ShellyHandlerFactory] - Shelly Plug-S: Create new thing of type shelly:shellyplugs using ShellyRelayHandler
16:08:37.163 [DEBUG] [.shelly.internal.ShellyHandlerFactory] - Thing handler for uid shelly:shellyplugs:8c3b28cc45 added, total things = 1
16:08:39.180 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellyplugs-8c3b28cc45: Device config: Device address=192.168.30.11, HTTP user/password=admin/***, update interval=60
16:08:39.181 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellyplugs-8c3b28cc45: Configured Events: Button: false, Switch (on/off): false, Push: false, Roller: true, Sensor: true, CoIoT: false, Enable AutoCoIoT: false
16:08:39.183 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellyplugs-8c3b28cc45: Start initializing for thing Shelly Plug-S, type shellyplugs, IP address 192.168.30.11, Gen2: false, CoIoT: false
16:08:39.303 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellyplugs-8c3b28cc45: Unable to initialize: GET http://192.168.30.11/settings > Not Found, retrying later
16:08:39.305 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellyplugs-8c3b28cc45: Update status job started, interval=20*3=60sec.
The IP 30.11 is the plug. When trying to use /status or /settings as I seen above, it responds “Not found”.
Based on this being Gen 2, I am not sure why the binding is trying as Gen 1? Am I missing a config somewhere?
Ok, nevermind the above. There is another plug type which matches the new gen and works fine.
Would it be possible to allow port number in deviceIp
When i connect a 1PM thru a plus device with Range extender enabled it gets external adress 192.168.194.35:8017.
try it and send a TRACE log
there is a good chance to get that working
I have the same …
again
- add the corresponding thing manually
- enter IP:port
- try it and send a TRACE log
Yes Shelly2 is supported
Like my example:
Thing shelly:shelly2-relay:S2Relay1 "Shelly Hühnerstall Tür" @ "Hühnerhaus" [deviceIp="192.168.178.71:8002", userId="adi", password="NochGeheimer", eventsCoIoT=false]
Do you mean frontail trace?
Did anybody manage to add a Shelly Smoke Plus device by a scan?
My device got an IP-address, access via browser works fine, I woke up the device by 3 times pressing the button but still it does not automatically detect the device. Adding it manually works.
no, go to the OH console and enter
„log:set TRACE org.openhab.binding.shelly“
initialize thing
and check openhab.log / post relevant extract
Today we had a smoke alarm in the kitchen and the device appeared in the inbox.
So discovery seems to work to some degree:
2023-08-14 08:50:52.563 [INFO ] [openhab.event.InboxAddedEvent ] - Discovery Result with UID 'shelly:shellyplussmoke:7328231915934' has been added.
@markus7017
All my smoke sensors are stuck in CONFIG PENDING and don’t advance to ONLINE (uptime > 1 week).
Thing shelly:shellyplussmoke:kueche "ShellyPlusSmoke: Küche Rauchmelder" @ "Küche" [deviceIp="ip"]
Since they are stuck the thing never creates the smoke / mute channel:
Imho this is very concerning because that way the smoke alarm does not get propagated to the corresponding item. The whole reason I bought a connected smoke alarm is to have a push notification and trigger some rules in case of a fire.
Today the alarm was not propagated and I did not receive a notification.
Would it be possible to statically add the smoke sensor to the shellyplussmoke thing so it at least works every time even when the initialization is stuck?
With battery powered devices the initialization can quite some time (one to a couple of days). During that time no values or alarms will be processed. This is especially bad for smoke / flood alarms.
After a while the thing should go into online mode, probably after 15 minutes which is the default statusintervall of the binding. At least this is how it works on my side.
I second your idea to have a static connection. Athe moment I manage this by adding an action within the smoke detetector. I installed an http-listener binding which can receive http-get requests and change the state of an item. But it would be nice if the binding had a thing channel which can be accessed from outside through http-get.
Just for completeness. I do not think that the Alarm channel you are referring to in your screenshot is triggered in case of a smoke detection. You have to use this one:
I think you misunderstand my point.
The correct alarm channel gets only created during the device initialization.
That means that even though I have configured everything correctly the smoke alarm from the device will not be sent to the item in case the initialization is not successful, hangs or has some other error.
This is my items file:
Switch Rauchmelder_Alarm "Küche Alarm [%s]" {channel="shelly:shellyplussmoke:kueche:sensors#smoke"}
Switch Rauchmelder_Lautlos "Küche Lautlos [%s]" {channel="shelly:shellyplussmoke:kueche:sensors#mute"}
Number Rauchmelder_Batterie "Küche Batterie [%d %%]" {channel="shelly:shellyplussmoke:kueche:sensors#batteryLevel"}
String Rauchmelder_Fehler "Küche Fehler [%s]" {channel="shelly:shellyplussmoke:kueche:sensors#lastError"}
String Rauchmelder_Ereignis "Küche Ereignis [%s]" {channel="shelly:shellyplussmoke:kueche:device#alarm" [profile="system:trigger-event-string"]}
As you can see I have linked the Rauchmelder_Alarm item to the correct channel.
However my thing hasn’t created the corresponding channel (see screenshot) because the initialization is not complete yet.
I just wish that these channels either
- will automatically be created when the thing is created
- there is an option in the thing config to manually specify the channgels (e.g. like in the generic mqtt thing)
That way I would not have to depend on some initialization routine which seems to behave rather flaky.
Reporting of e.g. the battery level already works but I’d argue the smoke alarm is the more important one!
2023-08-11 04:20:54.722 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Rauchmelder_Batterie' changed from 91 to 92
2023-08-12 04:12:21.391 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Rauchmelder_Batterie' changed from 92 to 91
2023-08-14 03:55:30.818 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Rauchmelder_Batterie' changed from 91 to 92
PS:
Using the alarm channels does not work for any of my devices.
The gui shows it set up properly for ...:device#alarm" [profile="system:trigger-event-string"] but the items remain NULL even though for battery powered devices it should show at least PERIODIC
Does anyone have any idea?
it seems for me this works. i also have installed several shellyplussmoke sensors and connected via wlan.
i have a habapp rule:
trigger = f'shelly:shellyplussmoke:{self.chn_id:s}:device#alarm'
self.listen_event(trigger, self.triggered_chn, EventFilter(ChannelTriggeredEvent))
def triggered_chn(self, event):
'''
Rauchmelder meldet sich, channel triggered, Lebenszeichen in nicht festgelegten Abständen
'''
channel = event.name
self.log.debug(f'### Shelly Plus Smoke {channel} meldet sich ###')
event_prefix = channel[:channel.rfind(":")]
node_prefix = 'shelly:shellyplussmoke'
for thing in self.get_items(type=Thing, name=f'{node_prefix:s}'):
if str(event_prefix) == str(thing.name):
self.log.debug(f'### Shelly Plus Smoke {thing.label} meldet sich: \n'\
f'Channel = {thing.name}\n'\
f'event.name = {channel}\nevent = {event.event} ###')
that logs me:
2023-08-14 02:48:04,511 [DEBUG] [My_HABApp] - ### Shelly Plus Smoke shelly:shellyplussmoke:xxxxxxxxxxxx:device#alarm meldet sich ###
… but interesting to know as long as the thing shows configuration pending it will not send an alarm. i realized sometimes it takes up to 22 days until the sensor sends next alive signal.
1 Like
I’ve added a quick rule to track the wake up times of the battery powered shellies, too.
Thank you for the inspiration!
Yes - it’s far from optimal! You can never know when your rules and sensors will work again after e.g. a restart.
1 Like
Status CONFIG_PENDING means that the device was discovered, but did not connected to OH for now. What do you expect in this state? Once the device connects (via CoAP event or WebSocket event) the thing goes ONLINE. You should not keep a battery in state CONFIG_PENDING. After a OH restart or changing batteries you should press the button to make there that everything is fine and things are ONLINE.
What does that mean? You should make sure that device and channels are discovered correctly when installing a new device.
Again, make sure that devices are ONLINE after maintenance. On the other side the device usually connects in a certain interval (I think every 12h). If devices stays in status CONFIG_PENDING for > 12h something is wrong.
I thing it’s agood chance to contribute with testing and provide details if you encounter a problem.
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.