is there a max?

[ReneTode]

is there anyway to know how many lights 1 hub can support without a problem? i got many lights on 2 hubs, and lately i get unexpected behaviour. (light A turning on results in light B dimming, even after changing groups 2 times)

[Linkenelis]

Hi,

there is always a limitation... But how many lights need to be changed per minute (or 5 minutes)? There is only 1 sender/receiver between hub and lamp (bulb). So it depends on a couple of things there like repeat packages and how many commands and a couple more. The ESP8266 limit is not in the bulbs directly, but by the nbr of device ID's (how many original MiLight-hubs should be emulated).

"many lamps on 2 hubs" is not very specific :-) can you upload the settings file? 2 hubs (device ID's) on 1 ESP8266? or 2 ESP8266? How many bulbs per group?

I have 1 ESP8266 with 2 device ID's, using a total of 6 groups (4 on device ID 1 and 2 on device ID 2) and 19 bulbs in total. largest group has 7 bulbs, the rest are less per group. No problems.

"lately" suggests it has worked fine before?

• what has changed?

[ReneTode]

2 ESP8266s A) 1 with 17 groups (59 lights) B) 1 with 7 groups (17 lights)

the problem i got is that lights connected to hub B (only 3) are dimming when i turn another specific light on hub A on. that started happening after i added a those new lights to hub A i already unpaired those lights and did chose another group, 2 times, but the problem exists.

so i wonder if it can be a stability thing from hub A

im still on a very old version on hub A, but im afraid that when i try to update ill need to reconnect all lights (and with almost 60 lights thats no fun)

settings file doesnt contain much info (but things like PW, ports, etc.) what would you like to know from my settings?

[Linkenelis]

I don't need the passwords :-) Just to see if deviceID's, MQTT or UDP are not messing things up. Very strange that on/off switching causes some others to change brightness. Is there MQTT involved (can it be an action there)?

So 3 lights on B change brightness when turning on a group on A? After adding some lights to A? New deviceID or only group?

To find the cause: Does this also happen with ESP B powered off? Or giving that command with the new lights NOT in the socket (and ESP B still off)? Then it is in ESP A If not: Power on ESP B and try again If not: could it be the (new) bulb(s)? connect 1 by 1 and check

[ReneTode]

i use MQTT and i use the hub for a very long time now, and nothing like that happened before. and because i never change settings there, i dont think its anything in there.

i added new lights. all my lights are seperate so group X, nr Y after i noticed that it happened i did unpair the new lights and changed my new lights to group Z, nr Y because i suspected interference (happen 1 time before) but even after changing to 2 different groups the effect stayed.

havent tried with ESP B off, but i did set ESP B to sniffing mode when i turned on the lights. ESP A and ESP B are in areas that cant reach each other anyway (thats why i created ESP B)

it also happens when the new lights are not connected.

im pretty sure its ESP A. and thats why i suspect a limit. because when i take off the lights that cause the effect, and put in others on the same place it happens also.

[ReneTode]

as a solution im planning to add another hub, that i newly create with the latest software. ill take off some load from ESP A and see if it will effect the same way, when i add the lights there.

i dont know why, but in the meantime more lights from ESP B seem to be effected. but only those that are in reach from both ESPs

[Linkenelis]

Yes, i figured someting like that. Still, an on/off command that influences the brightness (or level) of another bulb is weird. And can (normally) only be done with some scripting. Good luck! a lot of unpairing/pairing...

[ReneTode]

all my automations are in appdaemon, and there is really no connection between the new lights and the effected lights (every bulb has its own app anyway)

but controlling 80 lights (and still around 20 lying around) seems to get more difficult with every light i add.

i keep track from all paired bulbs like this:

# 0x19   1 trap beneden
# 0x19   2 terras roosbak
# 0x19   3 mancave wasbak
# 0x19   4 trap boven

# 0x1A   1 wandmeubel
# 0x1A   2 keuken boven vitrine
# 0x1A   3 kelder theke (hub kelder)
# 0x1A   4 keuken kookplaat

# 0x1F   1 rgb cct frietkeuken kastje links
# 0x1F   2 rgb cct frietkeuken kastje rechts
# 0x1F   3
# 0x1F   4

# 0x255  1 moestuin lantarenpaal 2
# 0x255  2 rgbw kleine nis
# 0x255  3 rgbw televisie
# 0x255  4 rgb cct koffiehoek

# 0x2B   1 rgb cct keuken koelkast
# 0x2B   2 rgbw boekenkast
# 0x2B   3 rgbw vitrine
# 0x2B   4 rgbw slaapkamer bed

# 0x34   1 rgb cct plafondspot 1 (hub keller)
# 0x34   2 rgb cct plafondspot 2 (hub keller)
# 0x34   3 rgb cct plafondspot 3 (hub keller)
# 0x34   4 rgb cct plafondspot 4 (hub keller)

# 0x38   1 rgb cct keller heren toilet (hub kelder)
# 0x38   2 rgb cct keller dames toilet (hub kelder)
# 0x38   3 
# 0x38   4 

but i also wonder what would be the best way to chose groups that are not interfering. is it better to keep them all together? or spread it out like i try to do?

[Linkenelis]

Yes with so many it is good to be organized ;-) For myself I can still remember them all... So I am not able to help you there, just the regular things for interference as you then have 100 extra units in the 2.4 GHz band. Radio settings:

• Listen and send on only 1 channel (min; mid; high)
• maybe this can help? First esp on min; second on mid etc
• with more esp can you reduce the powerlevel?

[ReneTode]

i looked through my settings, but i dont find anything about channel choice what do you mean with min, mid, high?

i did some more testing. took out ESP B, and the lights paired to ESP B still reacted to command i did send to ESP A i did take out the lights that i did send the commands to, problem stayed. i did move my ESP A 1 floor up, problem stayed.

so im 100% sure its in my ESP A. so im going to create ESP C, as soon as possible.

and off course then i need to repair lights, and i always wondered: is it better to use groups that are close or far from another? so do i better use: 0x1A, 0x1B, 0x1C, etc. or better 0x1A, 1x1A, 2x1A, etc.

at the moment the group 0x34 on ESP B react to changing 0x19 from ESP A and 0x42FF from ESP A change lights in group 0x38 from ESP B (but i did already change 0x42FF after trying 2 others) but that might be because ESP A is overloaded.

[Linkenelis]

nRF24 listen and send channels, see screenshot. Settings -> Radio min; mid; high are 2.4GHz channels It looks to me that your environment has a lot of 2.4GHz usage?

It needs to start with 0x; then a 4 char hex (0x19 = 0x0019; or binary 0001 0001 ) To keep it logical as well as good seperation (all deviceID's on another ESP at least 2 bits different), I would go for:

• ESP A: 0x1000; 0x1011; 0x1022; 0x1033 (binary 0001 0000 0001 0001)
• ESP B: 0x6000; 0x6011 etc (binary 0110 0000 0001 0001)
• ESP C: 0xA000; etc (binary 1010 0000 0001 0001)

[ReneTode]

yes i got a lot of 2.4 Ghz a lot of wifi is still on 2.4 and i now also started using zigbee.

those setting did come in later on. my hubs dont have those settings yet. any clue what the default was before it got implemented?

thx for clearing me up on the groups. i though 0x19 would translate to 0x1900

ill start thinking about how to keep it apart, but starting all over would be hell. first ill create a new hub that is up to date, set that to high, and take out the trouble making lights from ESP A and move them to C. then ill look how many more i can take out easy, to get more organised.

[Linkenelis]

So you are an early adopter! I havent used the early versions, my guess would be all 3. Even now that is the standard setting for sending and the standard for listening was changed 2 years ago to RF24_LOW... from settings.h: Settings() : adminUsername(""), adminPassword(""), // CE and CSN pins from nrf24l01 cePin(4), csnPin(15), resetPin(0), ledPin(-2), radioInterfaceType(nRF24), packetRepeats(50), httpRepeatFactor(1), listenRepeats(3), discoveryPort(48899), simpleMqttClientStatus(false), stateFlushInterval(10000), mqttStateRateLimit(500), mqttDebounceDelay(500), mqttRetain(true), packetRepeatThrottleThreshold(200), packetRepeatThrottleSensitivity(0), packetRepeatMinimum(3), enableAutomaticModeSwitching(false), ledModeWifiConfig(LEDStatus::LEDMode::FastToggle), ledModeWifiFailed(LEDStatus::LEDMode::On), ledModeOperating(LEDStatus::LEDMode::SlowBlip), ledModePacket(LEDStatus::LEDMode::Flicker), ledModePacketCount(3), hostname("milight-hub"), rf24PowerLevel(RF24PowerLevelHelpers::defaultValue()), rf24Channels(RF24ChannelHelpers::allValues()), groupStateFields(DEFAULT_GROUP_STATE_FIELDS), rf24ListenChannel(RF24Channel::RF24_LOW), packetRepeatsPerLoop(10), wifiMode(WifiMode::N), defaultTransitionPeriod(500), _autoRestartPeriod(0)

[ReneTode]

So you are an early adopter!

my ESP A is running for over 4 years now.

version 1 was released end of 3-2017 and if i remember correct i installed it first on 5-2017 and updated shortly after that 1 time. i believe im running version 1.4 on ESP A. ESP B is from a year later.

i started in the time that milight was still cheap. if i would start now i would go for zigbee. but with 100 lights already here (a total investment from near 1000 euro) im not throwing it away anymore ;) but i wont expand anymore, so if i get my problem out of the way with the third ESP it will stay with that.

[Linkenelis]

Zigbee is also 2.4GHz (sometimes 868 MHz) and not that different? But you will have more companies to chose from. And yes switching systems always brings an investment write-off... I am using iobroker (a jail running on my NAS) as the system to control everything, mainly via MQTT (iobroker has a build-in MQTT server). MiLight via MQTT and UDP.

controling ESP8266; ESP32 (cam); MiLight-hub; sonoff/tasmota

Switching to Zigbee could be done here per bulb, or per room (If you want to keep the bulb coloring in the room the same). Just another plugin in iobroker.

I would like to hear the progress. Your setup is a special one.

[ReneTode]

this is not really the place to have off topic chat, but if you like you could always come to the appdaemon discord server. im very active with appdaemon and control everything with that. https://discord.gg/3fH9jyZtd5

but ill post at least here if i got the milight stuff working without trouble again. tonight im trying to get ESP C up and running.

[Linkenelis]

Just thought of something.. A bulb is paired to a device ID. In the new ESP, just set device ID to an existing one on ESP A, like the 0x19. I think it will switch the groups on both devices. Saves you a lot of pairing! When everything works, you can start deleting from the old one (or not)

[ReneTode]

great idea!! thx that works.

ill first add them all (from ESP A) to the new ESP. if the problems then are solved i can keep just that 1. if not i can make the old one up to date, and then split them up.

[Linkenelis]

Sounds like a plan

[ReneTode]

to bad that the plan failed.

i added light after light and at some point i thought i missed lights that i already added. added some more, and now they are ALL gone again.

my ESP is not good enough to keep that amount of settings for sure. and with the aliases added it obviously takes up even more space to save the settings. so its breaking down sooner.

its nice to think the hub can have unlimited lights, but it seems that it isnt holding more then 50 (and with the newer versions even less)

but knowing that i dont need to pair everything helps a lot. im flashing ESP C again, add the lights that bugged me and remove those from ESP A to see how it goes.

[ReneTode]

hmm, the question is if settings are deleted in any way from my ESP A? it seems that i dont need to do anything on ESP C

if its new installed and i send mqtt commands it works without setting any setting on the hub.

so as far as i now see it, the only place where the pairing is saved is on the lightbulb.

[Linkenelis]

settings_buffer_size is set to 4096 in settings.h line 22 This 4096 is then the size of a DynamicJsonDocument and written to spiffs So if you have the space (i think you do) you could try to increase that in platformio and build.

check the settings in a browser with the rest api: ipaddress_of_ESP/settings

I think you run into this 4096 limit

Yes the pairing is saved in the bulb. So if you add the device ID it has been paired with, it should work.

[Linkenelis]

If aliasses take to much space, don't use them... I think your system is setup using device_ID's and Group_ID. just enter the device_ID's

[ReneTode]

Yes the pairing is saved in the bulb. So if you add the device ID it has been paired with, it should work.

thats what i noticed and realised. i dont need to add anything. i can use 1 ESP (lets say ESP D) to pair everything and when it gets into trouble i can just reflash that 1.

and from ESP A, B and C i can control the lights without doing anything to those hubs.

[Linkenelis]

Yes, as long as they have the device_ID's

You can check the settings size here https://www.javainuse.com/bytesize copy the result of ipaddress_of_ESP/settings into that webpage

[ReneTode]

Yes, as long as they have the device_ID's

no they dont even need that

[Linkenelis]

so if you send MQTT to an ESP it will just send the device_ID code, even when it is not in the settings? Oh golly! I have to check that.

[ReneTode]

yeah, as long as the lightbulb is paired you can send the mqtt topic to any hub you like. thats what i just found out. so you can control every paired light from every hub you got, and you only need to pair it to 1 hub.

[Linkenelis]

So the settings are just for usage via webserver (and you need that for pairing)

[Linkenelis]

This way there is no limit, if you can do without the webpage...

[ReneTode]

yeah, in my old version they were not even visibly saved i thought that they were saved in the background. if they are saved its for usage in the webserver only.

gets me to the point why my old hub is breaking down and sending conflicting signals all of a sudden? i now changed my settings so that the conflicting lights are send from the new hub. tonight ill find out if that works.

and when so i can reflash my both other hubs to get them clean and up to date tommorrow without changing any settings.

[Linkenelis]

Well at least we learned something! BTW if it is done all via MQTT and all your devices have the same MQTT patern (starting with milight), they will all send every command. If thats your wish, then fine. Otherwise give them different patterns.

[Linkenelis]

__gets me to the point why my old hub is breaking down and sending conflicting signals all of a sudden? That's what I mean, with the same patern as the new one you will still not know. Both units are sending...

[ReneTode]

no every hub has its on starting topic. ESP A > milight# ESP B > milightkelder# ESP C > milightnew#

so i target every hub specificly.

so i flashed ESP C clean. then i changed a few commands from milight to milightnew, and it works like a charm. tonight ill test if the interference is still there after that.

[Linkenelis]

Great! Did you make any changes to the channels? Or are you waiting to see what happens now?

[ReneTode]

no i kept it like it was. i did split it though (but i guess with what we know now, thats hardly usefull ;) ) later on ill go to the area where the lights live that are annoying me.

i dont want to create new automations or ask my wife to flip switches, so im waiting for the right moment to see what happens.

so to be exact all i did:

1) create new hub with topic milightnew/# 2) in my automations change "milight" to "milightnew"

but i just noticed, that there is 1 thing in the new hubs software that wasnt there before: the latest software listens for signals in the air and sends those to mqtt.

so hub A is actually functioning as a remote for HUB C now. the old software didnt listen at all.

so i get some kind of feedback now that is very interesting. appdaemon > mqtt > hub A > hub C > mqtt > appdaemon

because of that i can see that hub A did send the command, and which command.

[Linkenelis]

_the latest software listens for signals in the air and sends those to mqtt.___ Yes, All sending devices (in range) will show up in MQTT with the device_ID. I have a MiLight T4 that has ID 0x2227 and it confused me a lot, than my light went on ;-) The T4 is nice for the family, but a nightmare to pair as it is fixed to the wall. But MQTT makes you aware of the device_ID, so you can enter it in an ESP and use a mobile phone and the webpage to pair. So yeah, I did not realize, but with 3 units you will see the result of what you are sending in the MQTT of the others. You should be able to see what goes wrong! Sending On/Off and receiving brigtness or level...

Something else entirely: I have MyLight working (stable) on an ESP32 (TTGO T7 1.4). I now have a display connected and that run via the second processor. But I lack inspiration of what to do with it... Sure I can toggle the lights and brightness and so on, but that is a hassle to build and brings nothing new (as it is very convenient in the browser). So it has the extra ram and processor, even a battery backup.

Any thoughts on this are appreciated!

[ReneTode]

changing from hub A to hub C didnt change anything. so my thoughts at the moment:

some deviceIDs interfere with others. so why do i suddenly have more trouble? possibility: the lights that now recieve the interference are in an old winecellar, with very thick walls and ceilings (thats why i got hub B there) normally those lights dont recieve the signals, but its summer, the humidity is higher and also in those walls/ceiling. that makes it possible that signals that normally wont get through, now get through.

now im going to try to find deviceIDs that dont conflict. which is annoying, because now i know for sure there is interference between deviceIDs. so every time i add a light, i should check if it doesnt make 1 of my other 80 lights go crazy.

about your other issue i think we better talk on discord (if you like in PM) to keep this issue clean for others in the future.

[ReneTode]

i found my troubling lights and they were not the ones i suspected. both 0x5BA1/rgbw/1 and 0x19/rgbw/1 did change 0x34/rgbcct/1, 2, 3 and 4 and 0x38/rgbcct/1 and 2 and 0x4BFF/rgbw/1 and 0x4BFF/rgbcct/4

and i already had 0x4BFF/rgbcct/3 sorted out as conflicting also

the reason i didnt find 0x5BA1 as troublemaker is because its not connected to a real bulb. i used that as a fake light to connect alexa with emulated hue, so that i could easy connect routines to automations (completely different story) a few of those routines were triggered by alexa flex with motion sensor. and i never thought of that fake light causing trouble, because i use it for years now.

so i learned a lot, and tried to tell everything i experienced, so that others might be helped.

[Linkenelis]

Thanks for sharing this interesting case!