homieiot / homie-esp8266

💡 ESP8266 framework for Homie, a lightweight MQTT convention for the IoT
http://homieiot.github.io/homie-esp8266
MIT License
1.36k stars 306 forks source link

Current State of node property #421

Open hemaltandel1 opened 6 years ago

hemaltandel1 commented 6 years ago

Hello,

Great project. Thank you very much for all your hard work.

I am trying to retrieve the current state of each node property on-demand but not able to find one.

It's publishing the state of property, when it we set the property but how i can just get the current state of property without setting it?

Regards, John

bertmelis commented 6 years ago

There is no on-demand publishing. It has been requested (a few times) and after some discussion the conclusion was to not implement it. All values are sent with the retained flag set, so as soon as you subscribe to the appropriate topic, your broker will send the last known value.

A possible workaround is to create a settable "worker-node". This node could trigger the device to update properties at the reception of a value. eg. node "worker" --> app settable property "update" --> send "updatenow!" to device --> device reacts with updating the other properties.

hemaltandel1 commented 6 years ago

Thanks @bertmelis . Is there any specific reason not to implement it? How mqqt broker will update node property value if node property set before MQQT connected. I really don't understand the workaround. A brief example will be appreciated.

bertmelis commented 6 years ago

https://github.com/marvinroger/homie/issues/23

the example below is very incomplete.


unsigned long lastMillis = 0;
bool sendValue = false;

bool sendExtra(const HomieRange& range, const String& value) {
  sendValue = true;
}

//...

void loop() {
  if (millis() - lastMillis > 60000) {
    sendValue = true;
    lastMillis = millis();
  }
  if (sendValue) {
    //update your values and publish values with Homie
    sendValue = false;
  }
}

the sendExtra-function has to be assigned a set-handler of your "worker"-node. Every time the device receives any value via MQTT, the sendExtra-function will be called and the sendValue will be set.

euphi commented 6 years ago

@johnmay1 the basic idea behind MQTT (and thus Homie) is that device update their state as soon as it changes or frequently.

If the retained flag is set, the broker stores the value to send it to anyone how starts listening to a matching topic.

To handle the special case that the broker is resetted, you can send all known values when the MQTT connection is reestablished.

Homie does this automatically for its internal data.

Sent from my Sony D6503 using FastHub

hemaltandel1 commented 6 years ago

Hi @bertmelis . Thanks for code. Yes, we can write such code to report it but i am thinking to achieve it withing Homie internally, so we don't need to write such method for each node property.

@euphi , Thanks for explanation. Yes, i want to send node property current state if the MQTT broker re-connected. I can see that homie sending Device Properties, Nodes and Node Property using "advertise" method but i can't see it's sending Node Property current state when it's re-connected to a broker.

timpur commented 6 years ago

Is this something we think is worth needed ? or maybe something you can enable on nodes if needed ? @marvinroger @bertmelis @euphi

tripflex commented 6 years ago

Yeah I think it sounds like @johnmay1 is saying he wants to be able to retrieve the property value at some point in the code base.

This is actually exactly what I was trying to figure out how to do, and was surprised there isn't any way to do that as of now (without using settings). This is huge for me especially when there's a value set on CustomNodeA that CustomNodeB depends on

Reading here though, I think explains why this isn't something available: https://github.com/marvinroger/homie-esp8266/issues/106#issuecomment-233567582

timpur commented 6 years ago

I think the reason is if you are setting the node value at some point or you make the node setable then you should be able to store it in memory if you like when you set it in code or receive a set value from mqtt /set. Thus not forcing each node to always store the value in memory using precious resources.....

tripflex commented 6 years ago

@timpur yeah and completely understandable, in my specific case scenario these values would just have to be stored in config file (as some nodes rely on config from another node, which need to persist even after a reboot).

nerdfirefighter commented 6 years ago

From the discussions we have been have in issue #313, if its decided to implement a state.json file this can be used to track current state with out having to take up RAM/Memory. As calculated we can write to the file every 6 seconds and the device will still last 5 years with out burning out the SPIFFS. Architecture for the state file has not been discussed yet.