Please add the ability to obtain IP addresses via MQTT

[odis68]

Please add the ability to disable the output IP address in the MQTT

Thank you for your work !!!

[sidoh]

Interesting idea, but how does it help? You'd need the IP for initial configuration of the ESP8266 anyway (including setting up MQTT server info).

[odis68]

It is necessary to obtain the IP address from MQTT. and do not prescribe the address is static. it becomes possible to manage GET requests to the address received via DHCP. If the address is issued by DHCP it is not possible to get at least via (http: //192.168.22.?? / gateways / 2222 / rgb_cct / 1) /, but it is advisable to stay on one MQTT protocol.

[sidoh]

So the use-case is for devices that are configured, but IPs change? Do mDNS and SSDP not work for you? Both of those things are supported.

[odis68]

The network is closed under 'NAT' and you can configure mDNS, but again we get the settings in two places as NODE -RED recognizes the name. You have some options working through GET, I would like to receive an address on request or periodically in the form of statistics to configure everything in one place. The difficulty is that it will lead to the configuration of another router. Then it's easier to set up a static address. I wanted to get IP and mDNS by MQTT.

[sidoh]

I promise I'm not trying to be dense, but I'm not following exactly what you're asking for.

You say you want to disable the output IP. What does this mean?

[odis68]

Sorry, I am writing through a translator. I do not ask to disable IP :). I really want to be able to configure only in one place. MQTT in your implementation does not allow flexibility, unlike GET requests. It will be convenient if the management system receives the address and domain using the MQTT. I understand that this is not required for everyone, so it is desirable that this feature be disabled. for example, once every 10 minutes so that the controller status message arrives and its address is specified outside. and then, without the settings of the router, get the address of the device. or if it is possible to implement the functionality of GET requests through MQTT. Getting the status of groups on request. because if the broker rebooted or milight_hub was reset then the MQTT does not know the state of the controllers.

[sidoh]

Getting the status of groups on request. because if the broker rebooted or milight_hub was reset then the MQTT does not know the state of the controllers.

Perhaps I'm missing something, but this is not a feature that makes sense to me. When state for a gateway changes, an MQTT update is published with the retain flag set to true. When new clients subscribe to the state topic, they're sent the state by the MQTT broker. MQTT is pushing updates when they happen, rather than relying on clients to poll and watch for changes.

My guess is that it doesn't make sense to optimize for the MQTT broker going down. I've been using mosquitto for years and it's never once gone down.

[odis68]

Well need such a script. it is necessary to lower the brightness and then return to what it was (this is necessary to indicate the reaction to the control panel, for example, to change the preparation of the TV and other equipment for evening viewing or to turn off after a certain time). if the broker did not receive changes over a long period of time and then there is no possibility to accept that the broker received the state) after the light was turned off or the error occurred, the state on the lamps themselves, esp8266_milight_hub, and the broker state, become out of sync. This function is when using GET but NODERED does not know where to send (you can configure the router, but if the address changes or the hardware changes again, you need to configure it) it is preferable to get commands like GET https://github.com/sidoh/esp8266_milight_hub#rest-endpoints

[sidoh]

It sounds like what you're asking for is a way to query for state updates via MQTT. Is that right?

There is not state information available in the REST API that is not available via MQTT. The last-reported state on the MQTT topic will be the same value returned by the REST API.

State reported by espMH is best-effort/open loop. When it sees or sends a command, it applies it to the state. If something happens to the bulb that espMH doesn't see (some other device sends a command that isn't picked up, or power to the device is turned down), state is going to be wrong. There's no way to know what the true status of the bulb is. There is no way around this.

[odis68]

I am not aware of the status of the lamp, but of the condition of the esp8266_milight_hub if the broker or the Nodered was reset

[sidoh]

Can you help me understand how nodered or the MQTT broker being reset results in undesirable effects in your setup?

[sidoh]

HI @odis68, any thoughts on this?

[rejoe2]

Imo this could be closed as it's included in the birth message/LWT #418