If Shelly Manager reports an NPE it might be related to a specific value/state returned by the device handled improperly. You should turn on DEBUG logging and check openhab.log
Yes, you’ll find DEV builds for 3.4.2 and 4.0 in my myfiles repo under shelly. If you are on 3.4.1 use the version coming with the Dist.
@Spaceman_Spiff@Oliver2@bastler The binding creates most channels dynamically on thing initialization. However, if device access fails or maybe some unsupported values are returned this process is aborted. I wondering why channels are removed from an existing thing, because the binding never delete existing channels, but adding missing ones (e.g. new version of the binding supports additional channels). Sometimes the are left-overs in the OH cache, esp. when updating the DEV build in the adding folder, try openhab-cli clean-cache.
@davorf You are right. A long time ago I separated color and white mode into 2 things having a clean channel layout. However, I see you point. I need to think about, what could be a good solution.
I have a Plus Plug S and Smoke on my desk and will add them soon (not this week).
I did a simple restart of openHAB and have not modified anything. I’m running on stable.
Almost all my devices are missing the channels (except maybe ca. 2-4).
Even with missing channels they properly show
the status ONLINE
Up to date thing information
The log shows no warnings/error.
When I tough the *.thing files with the configuration everything gets loaded and works as expected.
During the last two restarts this behavior occurred two times so it’s pretty much reproducible.
I’ve set all devices in CoIoT peer mode.
@markus7017
Would it be possible to at least add the basic channels of the appropriate thing? E.g. If I have configured a shelly:shelly25-roller then it’s safe to assume that there should be a channel
roller#control
roller#state
roller#input1
roller#input2
meter#currentWatts
meter#totalKWH
The device supported these since the start of sales.
Example configuration which should always have these channels:
Maybe an easy solution would be to specify a firmwareNewerThan configuration option?
Then I could add it to the thing file and it would allow proper initialisation without device configuration?
E.g.
Example configuration which should always have these channels:
I never saw, never heard about an issue like that. Did you tried an older firmware?
We should investigate the root cause and not build work arounds.
As I said, the binding doesn’t delete channels. Turn on TRACE, the channel creation is shown in openhab.log
The is no acknowledgment by the device and the binding doesn’t repeat commands on errors. Even in this case it doesn’t make sense, because the device entinto sleep mode and is no longer available. There is no way to wakeup a Shelly.
You could create a watchdog. When a command is processed correctly the device sends an status update. You could create a rule, which
sends the temp change to the device
and checks after 5sec that the new target temp is the desired temp
Most of my devices are on 1.11.7 from end of 2021, some are on 1.12.1 So not the latest but not really “old”. Both versions were equally affected
I agree, however having a sensible set of default channels (e.g. for a shelly25-roller a shutter channel) definitely makes sense.
The thing only gets created when the *.thing file gets loaded, so of course the binding can’t delete channels.
Maybe the problem is because I’ve set the device into CoIoT peer mode it doesn’t answer some kind of broadcast (or it takes too long) and when the thing is created from the file the required information it not yet available. However I’m just guessing.
@markus7017 : Thanks for your reply. I’m sorry if this is a dumb question, but how does postponing calls to /shelly and /settings (hopefully) solve my issue, that the Shelly Buttons events aren’t recognized for a long time after an OH restart?
@markus7017 & @atetzner
For me its not a battery powered device. Its a regular good old Shelly1 and I have the feeling its network or process related on in the docker container.
My Shelly1 is configured to ColoT with IP:Port like this:
.23 is the IP of my OH3 server. its the dedicated IP of the OH3 container within the docker VLAN.
So now checking the service on OH server port 5683 from within the container. One has to apt install net-tools before:
While Openhab port is listening, the ColoT port isnt.
Also I cannot telnet tcp:5683 from the same local LAN, but can OH3 web port.
So in the end, I think the ColoT messages cannot be delivered to Openhab since the TCP endpoint is not available from shelly1 device point of view.
Any ideas welcome
As you can see from the netstat output, the CoIoT port is a UDP port. That said, I think this is the intended behaviour/output of netstat:
UDP is connectionless. Unlike with TCP, it has no concept of “listening”, “established”, “closed”, or anything like that. If a UDP port is open, it appears in the listing; if it’s not open, it doesn’t. There is no other state to display. Showing LISTENING or something similar in that column could imply that there are other possible states, and that would be false.
I think this is also the intended behaviour as telnet only works with TCP, as far as I know. Connecting to an UDP port and pretending it is a TCP port won’t work, as OH will not answer with the required packages to perform the TCP handshake. You could use nc to connect to the UDP port and send some bytes to it.
Edit: Sorry for just saying “everything you observed is the normal behaviour” - this obviously doesn’t help you with your problem. Maybe you could try to sniff the raw network data using Wireshark to find out, if the packages get delivered to the OH CoIoT port. If you find out, that the packages get delivered, maybe it’s the same problem as I have …?
UDP is a connectionless protocol, this ist the reason why you don’t see LISTEN state.
BTW: use “ss” command instead of netstat from net-tools. netstat is deprecated.
“ss” shows for UDP UCONN or ESTAB.
See my (working CoIoT) setup output:
You can also trace the network traffic with tcpdump on OH host if there are incoming Coap packets: tcpdump host <Shelly Device IP> and port 5683 -n -vv -X
Thanks for your explanations @igi and @atetzner .
tcpdump confirms receipt of UDP packages from the Shelly1 appx. every 15 seconds. When ringing the bell connected to my Shelly1 I even see more UDP packets flowing. So its not network or service.
Thanks for your help on this.
I can’t use matching binding (the one installed through Paper UI) because in that case I can’t switch between color and white modes.
I haven’t mention my use case earlier, so it might explain why I need it. When Plex is playing movie/TV show, mode is switched to color and color of the bulb matches dominant color of the Plex poster. When Plex is paused or stopped it switches to white light and predefined intensity.
It was mentioned that Shelly introduced a counter which is not reset with a powercycle but can be reset via API. Apparently this happened at some point because the API documentation has a reset_totals parameter. https://shelly-api-docs.shelly.cloud/gen1/#shelly-3em-emeter-index
But in my binding documentation for 3.4.1 I don’t find any trace of support for the reset action.
Is it just missing from the binding?
Anybody would be able to extend the binding for that action?
How does the Shelly manager decide whether to show devices or not?
I have 6 Shellys that were set up via text files and also work. When the manager is opened it says there are 6 devices but only shows 3.
Openhab 3.4.1 is currently running, but the error has been there for a long time, I think since 3.2.
The device filter is set to all. I have 2 Shelly EM with the same configuration. One is displayed (is the first entry without a name) and the other is not.
