Hi, i have developed a dynamic thermostat node.
node-red-contrib-dynamic-thermostat
I hope you test it and give feedback.
2 Likes
Could you add your git repo url to the node's package.json please, so we can raise issues, improvements, feedback, or even just check the code.
1 Like
Are you sure about the output payload being as it is? That means I can't feed the output directly to a GPIO pin, for example.
Also, what benefits does it have over node-red-contrib-hysteresis?
You mean it would be better to output only the status payload as boolean?
For my interest the node package you mentioned is to complex. So my node is much simpler.
It depends on what you see the is the main application for the node. If the main requirement is to send on/off signals to a GPIO pin, or to MQTT then ideally you would provide the facility to specify the payload format (0/1, "On"/"Off", true/false etc) and the topic in case it is going to MQTT. It that is not the main target use that you see for the node another output may be desirable. Presumably you have a use for the node yourself, what are you using it for?
I was also thinking about the input format...
Would it be better for users if the input format was;
msg.payload = current temperature
msg.target = target temperature
msg.hysteresis = hysteresis
Then the configuration could optionally be set dynamically by passing in just one msg...
1 Like
That may occasionally be useful but it should not replace the topic method.
really ? - I can't think of any other nodes that use multiple topics to set internal config parameters - so while perfectly allowable - it is a not a pattern I recognise, whereas using different properties is.
1 Like
node-red-contrib-pid for example. It is really useful when parameters are user variable. They can be written to retained topics in MQTT and then easily fed back into the node using wildcards and a topic convention that allows the parameter topic to be automatically generated from the MQTT topic.
In applications where these nodes are used the process value comes from a completely different source to parameters and to have to combine them somehow just adds complexity.
Also the node-red-simple-gate family of nodes use the topic to distinguish between data messages and control messages, which is a similar concept.
Node-red-contrib-ramp-thermostat also uses multiple topics for setting parameters, for the same reason, that the data and control come from different sources.
1 Like
@DenisMtfl - I can't check (because your git repo url is not displayed) but does the node persist it's configuration if node-RED is full deployed, or a system reboot?
For example, does it remember it's last target temperature setting and hysteresis settings.
If not, what state will the resulting output be set to.
ah yes - if you are using mqtt broker as a store then yes make sense.
I have just now updated the package.json. Thanks for the reply
1 Like
No it doesn't because I don't know how to implement this function. Right now I used the node context to store the parameters, after the flow is deployed the parameters are safe but after the restart the parameters are gone. I am very new to nodejs programming. So thanks for any hints.
2 Likes
Hm interesting point i think about it.
Apologies if this is a dumb question, but what is hysteresis, and if I were to use this how would I know what value to use? Also, I assume that the other parameters (target and current) don't care whether the units are F or C or K, as long as they are both in the same units. What 'units' is hysteresis in?
I also think that the documentation for hysteresis in the README may be incorrect - it looks like a copy-paste from the target topic. Also, all three mentions of 'temperature' in the inputs documentation section are mis-spelled.
Hysteresis is a dead band used around the target temperature to prevent the power being switched rapidly on and off due to noise when the temperature is close to the target. The power stays on until the temperature is greater than the target temperature plus hysteresis and does not switch on again until it is less than target minus hysteresis.
Set it as small as you can without rapid switching due to the signal noise.
1 Like
It doesn't matter what unit the hysteresis is. The importance thing is that target, current and hysteresis are the same unit. Because if you have an thermostat with a temperature it doesn't matter what unit it is if the thermostat calculates in the same unit. I think converting any units are not necessary. Do you unterstand my statement @SteveDonie ?
Well actually it does matter. It is, as you say, in the same units as the other parameters. It could have been a percentage for example.
I think no one is thinking about percent in temperature and thermostat settings. I don't understand the impact. Hysteresis are normally in the same unit as the temperature.
I have seen many temperature controllers where you set up a range and then parameters such as hysteresis are setup as percentages. Not recently though, I have to admit. It stems from the analogue days when things were setup with pots. The use of real units for configuration is a relatively new phenomenon. It took quite a while to convince a generation of control engineers that one could use degrees, psi and so on.
