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

RFE: Add config field(s) to output nodes #10

Open
jwildeboer opened this issue Dec 8, 2016 · 1 comment
Open

RFE: Add config field(s) to output nodes #10

jwildeboer opened this issue Dec 8, 2016 · 1 comment

Comments

@jwildeboer
Copy link

jwildeboer commented Dec 8, 2016

Problem: Right now it's a bit confusing to keep track of rf_address in flows for maxcube. To make life a lot simpler, I would propose to add one or maybe two config fields to the out node:

  1. rf_address - so that we can have one node per thermostat. This config field would override/replace any rf_address in the message payload. If a message arrives without rf_address in the payload, it would set it to the config value.

And maybe a bit forward looking, but nevertheless:

  1. room - maybe as dropdown prepopulated from the data we get from the maxcube. This in preparation of being able to hopefully set temperature for a whole room with more than one thermostat or that is controlled with a wall display.
@jwildeboer jwildeboer changed the title RFE: Add config field(s) to input nodes RFE: Add config field(s) to output nodes Dec 8, 2016
@jwildeboer
Copy link
Author

jwildeboer commented Dec 8, 2016

This could actually be useful for both the in and out nodes. With the planned change of one big array instead of separate messages, it would be useful to use the rf_address as filter to create in and out nodes that only emit/accept data for that specific device. At least the rf_address field. I still would prefer to have room_id based setup, but that's a bit too much to ask ATM ;-)

Also: I find it slightly confusing that maxcube_in node is under the Output category in node red and the maxcube_out node under input. Maybe this can be corrected/swapped in a future release?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant