search

sidoh / esp8266_milight_hub

Replacement for a Milight/LimitlessLED hub hosted on an ESP8266
MIT License
937 stars 220 forks source link

Zone 0 (all) doesn't work from ioBroker #205

Closed morrisb74 closed 6 years ago

morrisb74 commented 6 years ago

when using the zone-all it doesn't work from iobroker

sidoh commented 6 years ago

I'm not familiar with iobroker. How are you integrating with ESPMH? MQTT?

Please provide more detail on how to reproduce the issue you're seeing.

morrisb74 commented 6 years ago

Using the MiLight protocol (V6) The ESP is simulating 3 bridges for my MiLights

ioBroker is HomeAutomation software --> http://iobroker.net/

morrisb74 commented 6 years ago

Just found a little quirk, if using the zone 0 (ALL) the other zones (1-4) are not being updated in MQTT If you want to keep the states in sync, it might be nice to update the zones 1-4 too

sidoh commented 6 years ago

The internal state kept for zones 1-4 are updated, but are not fanned out to MQTT. I don't think it makes sense to publish an MQTT update to zone 0 and zones 1-4. They mean the same thing.

What exactly isn't working? What actions are you taking, what behavior do you expect to see, and how is that different than the behavior you're actually seeing? Ideally you could provide me a way (terminal commands would be best) to reproduce the issue you're seeing.

janLo commented 6 years ago

Maybe its useful to use zone0 just as a "virtual zone" and don't report a status of it to MQTT?

There are no "real" bulbs attached to zone0. What you change is the value for zone 1-4. Also it might be hard to guess which value is the right one to use for an automation, if the states for zone0 and zoneX differ. Then you have to guess by the age of the state or something similar.

sidoh commented 6 years ago

"virtual zone" is a nice way to describe zone0.

The alternative to updating zone 0's state (which is essentially saying "all groups now have this state") is to fan out the same state to all zones in the group, which is 4x-8x the overhead. Given that I'm already not happy with ESPMH's throughput, I'm hesitant to add another source of congestion for the network stack.

From a client perspective, the topic for the actual group is the one to pay attention to. It's always at least as recent as zone 0. The only place I can think of where there would even be an issue is when a client first connects. In this case, it might receive updates for both zone 0 and zone X as messages are published with the retain flag. If it receives the message for zone 0 after zone X, it might cause some confusion, but I sort of doubt that happens with most brokers.

morrisb74 commented 6 years ago

I'll see if I can get fix the 'quirk' in ioBroker itself maybe :)

Is there a way I can help debug the ioBroker to Hub communication ?

sidoh commented 6 years ago

If you can find a way to reproduce the issue that doesn't involve iobroker it'd be great. It sounds like it might just be a bug in the UDP handler, so testing the UDP API directly would be ideal. I can play around with it and try to reproduce when I get some time, but would saving me the bug safari would be much appreciated :)

sidoh commented 6 years ago

I assume that this is still an issue, but because I have no way to reproduce it myself, I'm going to close this. I'm more than happy to look at this if someone can provide a direct way for me to reproduce it.