Open dekatWin opened 1 year ago
Mhhh, I've never tested that. Thanks for reporting
Same effect here and I have the concern that this is responsible for another effect I have: one of two Shellies behind the range extender goes offline after a while (object becomes yellow). If that happened the Shelly is not able to be controlled by ioBroker anymore. A reboot of the Shelly and restart of adapter solves the problem for some hours, sometimes for the whole day.
I have the same problem, is there a solution for that already?
@helbgd nope, since the adapter is not designed for 1:n devices per connection. Just 1:1
Is there solution in future? I hope so... or perhaps simply take out this debug text ? Have unfortunately the same Issue.
Is there solution in future?
If someone will rewrite the complete adapter: yes. It's a lot of work because nobody expected that the same client connection must handle multiple devices.
Not sure if this issue is still relevant / existing but I found a solution.
You have to change the MQTT prefix of the shelly, which is connected to the range extender, to the same MQTT prefix as from the range extender.
You have to change the MQTT prefix of the shelly, which is connected to the range extender, to the same MQTT prefix as from the range extender.
Bad idea.
I can't decide whether it's a bad idea. I can only report that this has been working for me without any problems for about three weeks. The only limitation is that some namings are referenced to the shelly which is the extender.
An alternative would be to use the “original” MQTT adapter, which I also tested. Naming is not an issue there. However, this makes processing the data points significantly more complex...
Sampe Problem here with Shelly that has no WIFI Access directly and has to be used via range extender.
no nw info.
As stated above range extender is NOT SUPPORTED. Adapter is designed to be used withe devices connected 1:1.
Sorry, had not read that part.My bad.
Is it possible to supress those messages instead?
As state above such a configuration could cause other troubles too. If the shelly is not within the reachability of wlan you maybe could use a normal wlan extender so that the shelly gets a normal, dedicated IP Address.
I have the same Problem, with Shelly that has no WIFI Access directly and has to be used via range extender. Is there already a solution?
check if normal wlan extender / repeter can be used
As states here and (as far as I know) at the docu:
Shelly range extender is NOT SUPPORTED. Adapter is designed to be used withe devices connected 1:1.
Can anyone explain why using a normal wlan repeater or accesspoint is no option to solve this restriction?
Yes, I am using this shelly to switch the lights in my storage in the basement. The storage is next to a solar inverter that is intervening with the wifi. I have a shelly peo next to the inverter connected to ethernet and use it as a range extender. In my case installing yet another repeater is not very cost effective for a single shelly that only purpose is to save energy. My solution now is to disconnect this shelly and only use the timer. Still cheaper than a timer relais in germany.
However, I appreciate the work that went into the adapter and I am very thankful.
I'm sure that
Shelly device
All Gen2
Protocol (CoAP / MQTT)
MQTT
IoBroker Log:
My setup:
I have a Shelly Plus1PM set up as a range extender AP and another Shelly connected to it, both have different MQTT prefixes in their settings. 1. Shelly MQTT Prefix: "Outdoor_AP" 2. Shelly MQTT Prefix: "Outdoor_BluGateway"
My problem:
The Shelly adapter writes endless warnings in my log that something is wrong with the set prefixes, but it is absolutely correct, 2 devices on one IP, 2 MQTT prefixes. Please remove this warning if possible, it is just spamming at the moment.
The Shelly adapter is great, I thought my setup with a range extender would go wrong, but both shellys were correctly detected and created. Great job, thanks for always improving it!
Version of Adapter
6.4.1