A shelly over an another shelly

Setup, Configuration and Use Migration
,
1

Hello community,
I have the following setup:
The Shelly 1plus [IP=XXX.XXX.XXX.71] creates an access point to which another Shelly25 connects. Now I want to access the Shelly2 via OpenHab. Unfortunately, it no longer has a unique IP but is addressed with a PORT [XXX.XXX.XXX.71:8002].

Is it somehow possible to access the Shelly2 via Openhab?

Here is my Thing:

Thing shelly:shellyplus1:SRelay7        "Shelly Waldtoilette" @ "Schuppen"         [deviceIp="192.168.178.71", userId="adi", password="SuperGeheim", eventsCoIoT=false]
Thing shelly:shelly2-relay:S2Relay1     "Shelly Hühnerstall Tür" @ "Hühnerhaus"    [deviceIp="192.168.178.71:8002", userId="adi", password="NochGeheimer", eventsCoIoT=false]
2

Have you had any success with this yet?

3

You shouldn’t be attempting getting that going inside OH.
That’s an XY problem type of question and a network design failure in the first place.
Extend your WiFi properly e.g. using a repeater first. Then put both Shellies in.

4

It’s possible just use the IP of the Shelly that acts as an access point look Wich port allocated to the Shelly that connected to it and use that in openhab config

UID: shelly:shellypro2-relay:unit_5
label: unit 5
thingTypeUID: shelly:shellypro2-relay
configuration:
  enableBluGateway: false
  deviceIp: 192.168.6.83:8005
  password: pass
  updateInterval: 60
5

Sorry Markus, that‘s not correct. It is a new Shelly feature to repeat themselves. AFAIK, @markus7017 already asked for trace logs is configured with IP and port, to see how this can be supported by the binding.

6

Well, I disagree. Network design and higher layers must not be combined, that is a pretty unfortunate idea and somewhat fundamental violation of the OSI layering model.
If repeater functionality was implemented properly in a Shelly, it would be transparent to the user, i.e. the Shelly unit on the (repeated) far end would be in the same IP network and both would work with OH out of the box. Meshing in short. But if that doesn’t work, it shouldn’t be used that way.
I don’t mind @markus7017 or anyone spending time on attempting getting this to work, but adapting OH is IMHO the wrong approach and is likely leading to all sorts of problems (and I’ve seen MANY of those in my professional life that’s why I also object here) - in the end it’s a lot of wasted precious developer time.
I’d still call that an XY problem and think the proper answer still is: not the app developer has to support this edge use case but the user has to design the network right in the first place.

7

This is a build-in feature of the Shellys. It‘s kind of port forwarding. I already looked into this and will implement it, but needs some time. I‘ll be back home in a week and have some topics on the list. I‘ll post an update in the general Shelly bindjng thread

8

Any updates on this @markus7017?

9

I started implementation, butvery buys at the moment and need to complete the pending PR to get some critical fixes into the official build

1 Like
10

Is this implemented now?

11

Nope, I still need to complete 2 pending PRs. Due to OH 4.1 release we got stuck, hopefully we get this through soon. I’m currently fixing some reported bugs and added the Mini G3 series and Shelly Plus UNI.