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.

12

As the range extender is released by Allterco for some time now and functions very well on device/IP layer and together with the Shelly App (in my case a Shelly Pro 3 which does the range extension and a Bulb Duo RGBW with GU10 socket), everything looks good so far and worked on the first try! Got full control of the bulb over the network (internet browser) and the Shelly App! :blush:

BUT: has anybody gotten this to work with OH (4.2.x)? So on Shelly’s side, everything is working fine, but - at least in my installation - OH 4.2.1 release build on a Pi5 8GB, the included shelly binding does not recognize the connected bulb.
The bulb was formerly connected to my home’s WiFi directly where OH is also in the same net and also the Pro 3. But my WiFi outside the house is very weak and I tried to use the range extender of the Pro 3, which is mounted outside of the house in it’s own outdoor cabinet. I therefore enabled the range extender function and AP and the Pro setup its own WiFi and the bulb connected to it successfully. The bulb is reachable through the IP of the Pro 3 and a specific port - with internet browser I can access and control it fully. Also RSSI is good, so everything is working fine on device layer.
I then enabled the “range extender” function in the Pro 3 Thing in OH, disabled and enabled the Thing like it is mentioned in the docs of the Shelly binding and the newly discovered device (the bulb in my setup) should be found - but to no avail. Also restarted OH, rebooted the Pro 3, the bulb, updated firmware of the Pro 3 to the most actual 1.4.4 - no bulb is found.

So the question is: has anybody a working setup with a Shelly Pro device and OH 4.2.x and can control any of the connected device behind the Shelly Pro range extender through OH?

Any ideas, on what to look for in my setup? I am very very thankful for every hint or thought


Thank you all! :pray: