New feature: Repeater-Mode

[bombcheck]

Hi,

it would be great to have a "repeater mode", where the system sniffs for packets from another hub and re-sends them. Could be useful if you have a wide area to cover. :)

[janLo]

I'm not sure if this is a good idea with only one radio. It adds latency and because of the frequency hopping you're at risk to miss packets. Maybe just group you lamps to different hubs and give them disjoint mqtt topics. So you only need to make sure, that the wifi coverage reaches all hubs and you're fine.

[sidoh]

I've been thinking about something like this as well. I don't know enough about the nRF to say for sure, but my feeling is that janLo is right, a straight RF repeater would likely be unreliable. But the feature would be really useful, I think.

There are some other approaches I've been thinking about:

1. Several espMHs listening on the same MQTT topic. Could disable state updates from all but one of them. Repeat packets shouldn't be a problem except in some edge cases where packets don't define a state (like "set brightness to 50%"), but are instead deltas ("increase mode speed by 1").

2. Same as (1), but include a packet ID field in the command packet. This could be pushed into the RF packets, and would solve the duplicate problem. Adds obnoxious moving pieces.

3. Similar to the original idea, have master/slave mode. Would be similar to (2), except the ID field would be managed by the master.

janLo's suggestion is good as well, and has the benefit of not requiring any changes. :)

[Tertiush]

Just a though; what about a "master" hub broadcasting the command on your LAN (on its broadcast address) on a specific port using UDP. All ESPs listen on this port and simply repeats, perhaps with some selectable delay.....

[khmann]

Make it listen to multicast address! Then it goes everywhere automatically... Disable frequency hopping so there are no collisions. For me, "repeater" is the same as "macro controller" so I'm researching this idea

[sidoh]

I guess MQTT feels better to me than a custom UDP multicast protocol because:

1. Its structure already lends itself pretty nicely to the requirements.
2. The protocol includes security/authentication mechanisms.
3. It's a lot less work that cooking up a custom protocol :)

Only real downside is that it introduces a dependency on having an MQTT broker set up.

[sidoh]

@khmann you've certainly convinced me that it's silly to have the controller frequency hop. I can experiment with disabling this after the new year. Would you expect it to be useful to expose a way to select which channel is getting used? Or would it be mostly safe to just select one arbitrarily?

[khmann]

ha. It's easy to criticize, especially when you don't stick around to help ;)

One of the things I really like about your project is that it's a functional iBox "Reference Implementation". So perhaps fixed-frequency should be optional, as part of a 4-way dropdown next to retries: Hop/Bottom/Middle/Top, Auto/A/B/C, Diversity/L/M/H...? In the FCC, the high frequencies are much farther from 802.11 networks (10-11 MHz instead of 1-2 MHz (RGB[W,CCT])and so are the safe default, followed by the low ones because the "middle of the band" is always a gamble. If you were super-crafty, you could auto-select Lo/Hi whichever was farther from the WiFi channel you were using.

re: MQTT vs UDP sorry, I guess I had only ever considered the native milight UDP protocol - that one works out of the box if you just advertise with the broadcast MAC address. How you'd do it effectively with TCP MQTT stuff, I'm not even qualified to speculate

[RvonMallesch]

I can't up vote this enough. Do you think it is possible to make it into 1.7.0?

[sidoh]

I think all of the major features that will be in 1.7 have already been merged. Just working on getting it stable.

Open to including this in the next major release.

There are a couple of ideas being discussed in this ticket. Which are you referring to, @RvonMallesch? Repeater mode?

Is there a reason you couldn't just set up multiple ESPs listening on the same MQTT command topic? I thought about this earlier, and feel like there was some problem, but I'm not able to recall what it was.

[Skinah]

@sidoh , In regards to leaving the firmware how it is now and just using the same MQTT command to multiple hubs my gut feeling (i have not looked at your code to see exactly how you are doing it) is that you can not garantee what channel each of your hubs are broadcasting on. If two hubs broadcast on the same channel at slightly different times then the RF signals in the air will collide and the globes will miss the commands. I really like khmann suggestion to expose the RF channel as Hop/Bottom/Middle/Top, Auto/A/B/C, Diversity/L/M/H ( this is just the same idea listed three different ways and i will list a forth).

Have a user control which exposes four options ( I like AUTO, LOW, MID, HIGH) Auto/HOP = Guessing this is how you are doing it now. Low = the hub should only use low channel. mid =the hub should only use mid channel. high = the hub should only use high channel.

Then you can have up to 3 different hubs all using the same MQTT topics, you just set all three of them off the AUTO and onto each one to a different setting. You could remove the state MQTT topic on two of them so only one makes a single state reply or you could make them reply to different topics should u wish.

This would keep me very happy as I do not have range issues (easily solved with better nrf boards or lna+pa features), I want the feature for reducing latency to switch large amounts of globes faster with lower RF packet repeats.

If interested you can see my NRF tests here on how to extend your range. 200 meters (600 feet) range is not hard to achieve.

https://community.openhab.org/t/espmilighthub-new-binding-for-milight-limitlessled-and-easybulb/39720/46

[sidoh]

Definitely agree the channel settings is a nice feature. I'll prioritize it for the next major release.

[RvonMallesch]

Sorry for the late reply, it Is the channel settings I was referring my support for. I'm glad you agree! :-)

[janLo]

In the end you've 2^16 possible groups. So I think, with a bit of planning it shouldn't be necessary to have more than one controller listening to the same topic.