Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make exposed HomieNodes configurable on a per-device basis? #47

Closed
jpmens opened this issue Mar 23, 2016 · 2 comments
Closed

Make exposed HomieNodes configurable on a per-device basis? #47

jpmens opened this issue Mar 23, 2016 · 2 comments

Comments

@jpmens
Copy link

jpmens commented Mar 23, 2016

In #45 @marvinroger said something I find is important:

Homie sketches are meant to be portable.

Assuming I have a few ESP8266 sensors which could basically all run the same Homie firmware, most of which have the same sensors / actuators on them, but, say, one or two of them have no relay. I would write the Homie sketch as follows:

HomieNode lightNode("light", "light");
HomieNode relayNode("relay", "relay");
HomieNode tempNode("temperature", "whatever");

When the Homie device without the relay talks to me it would say "I have a relay!" which it doesn't. While this is just a detail, could we add an an element to the JSON configuration which basically says hide these nodes for this device? Something along the lines of

{
  "hide_nodes" : [ "light", "relay" ]
}

I could then deploy the same Homie firmware to all devices and have them report / react to only what they actually have.

This may be overkill and not too easy to implement, so please feel free to quickly close this. 😄

@marvinroger
Copy link
Member

By "portable", I mean a single firmware could be used by different people for their own same-hardware device. I did not think about what you're talking about here.

The idea is interesting, for an actuator (like a relay), the input handler would never be triggered, great. But for a sensor reporting values on a regular-basis, you would need to check in your own code if the node is enabled before sending a value.

It seems rather complicated to do. We need to focus on the stability of the framework, as you can see, adding a simple feature like the base_topic introduced a lot of heap issues. I won't close this, just in case, but I am not sure I will implement it. I am not comfortable with the idea of an all-in-one firmware. For my devices, I prefer a single purpose optimized firmware.

@jpmens
Copy link
Author

jpmens commented Mar 23, 2016

Fair points, and you're probably right, of course.
I'll close this proactively now.

@jpmens jpmens closed this as completed Mar 23, 2016
gorec2005 pushed a commit to gorec2005/homie-esp8266 that referenced this issue Jun 28, 2020
* New - server.rewirte() to rewrite the request url with optional get parameters injection.
New - rewrite.setFilter() and handler.setFilter() to specify a filter callback for more control on when to include them.
New - static file handler can be set with Last-Modified header value to support Not-Modified (304) response instead of serving the actual file.

* Remove clearRewrites & clearHandlers from server.mplement server distractor to delete internal members. Fixed and improved gzip stats calculation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants