Shelly Binding

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.

Source: windows - Why UDP does not show LISTENING in the state column in netstat? - Super User

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 …?

1 Like

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:

# ss -unlp | grep 5683
UNCONN 0      0                                     *:5683             *:*    users:(("java",pid=1508,fd=234))

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

1 Like

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.

1 Like

Hello!

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.

Anyway, thank you for your reply.

Best regards,
Davor

How do you get the dominant color of the Plex poster? Sounds very nice.

In case I missed a comment about the following topic I’m sorry. It’s quite a thread.

I own a Shelly 3EM Powemeter and were wondering about the total consumption which has been discussed a few times e.g. in https://community.openhab.org/t/shelly-power-meter-resets-total-consumption-on-power-loss/

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?

Hello!

Since this is topic about Shelly binding, I’ve opened another one, with explanation how to do this:

Best regards,
Davor

1 Like

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.

is device filter activated?

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. :thinking:

Do the missing devices also have an empty name? Maybe try to provide unique names.

The Shellys all have a name, see the things file

Thing shelly:shelly1:483fda82a0cf        "Shelly 1_1" @ "Hof"       [deviceIp="192.168.xxx.170", userId="", password=""]
Thing shelly:shellyem:d3b541             "Shelly EM1" @ "Keller"    [deviceIp="192.168.xxx.31" , userId="", password=""]
Thing shelly:shellyem:b9f094             "Shelly EM2" @ "Keller"    [deviceIp="192.168.xxx.108", userId="", password=""]
Thing shelly:shellyem3:40f52000e033      "Shelly 3EM" @ "Keller"    [deviceIp="192.168.xxx.32",  userId="", password=""]
Thing shelly:shellyflood:f2adbd        "Shelly Flood" @ "Garderobe" [deviceIp="192.168.xxx.109", userId="", password=""] 
Thing shelly:shellyplusht:7c87ce6bd1b0   "Shelly+ HT" @ "Bad"       [deviceIp="192.168.xxx.33",  userId="", password=""]

It seems that the names in the thing file cannot contain spaces. Should that be so ?

in MainUI spaces for thing names are allowed. Not sure for file based configuration

So the name displayed in the Shelly Manager is not the Shelly label but its network address and when I display the menu, the name is empty. But it shows up in the GUI.

The shelly name comes from the device itself (settings → device name). Not sure what effect it has but try to set your devices to discoverable: yes

1 Like

I had never given my Shellys a name in the device. Now I’ve done it and the Shelly manager is working again. Interesting that it worked without it until now.
Thank you

Quite useful: if you add new devices the binding uses the device name for the thing’s name.
Especially if you are using the dev binding from time to time you need to delete and re-add all things. By setting the device name in the device this task is done within a couple of seconds

This is not the reason. I have three shelly-plug-s which don’t even have the option to set a device name, but showing up with their network name in shelly manager. Might be that setting the device name just triggered a network announcement on the shelly devices which was then cought by the binding and shelly manager, finally resulting in showing up.

Not related to the problem in any way but Plug S do have the option to set a device name (unless you have a very old FW)