Hi,
I have built a HVAC control unit from CO2 / TEMP sensors (MQTT) which connect to TriAC unit and controlled via NodeMCU. MQTT data is transported to BLYNK virtual pins via NODE-RED Bridge mode ( thanks To Pete Knight on this ).
So now everything is working fine, but I wanted to also create a button for manual adjusting. Works great on the manual mode until either the CO2 or TEMP value is updated via MQTT, then those virtual BLYNK_WRITE pins are activated and Automatic mode gets activated again. Is there a way to code in blynk that if Blynk button (virtual pin is true), only that part is activated and no other update would get through, untill that Button / Pin is released?
I think youāre approaching this in the wrong way.
It sounds like youāre mixing Blynk and MQTT code in the sketch for your device. I would stick to MQTT only on the device, and allow Node-Red to handle the Blynk side of things.
In Manual mode when Node-Red receives an input from the CO2/Temp sensors it should be ignored or overridden (except maybe if they exceed certain limits and you want it to go into Auto mode again - a bit like when I tell my car to shift from 6th to 2nd at 120kph, it just thinks āhe didnāt really mean that, just ignore himā). You may also want manual override to end after a certain amount of time, or at a certain time of day (everything resets at 4am maybe).
So when I want to activate the Manual button, then slider value is perfectly used untill V5 or V4 are updated and then the V4 automatic calculation is reactivated. Same happens with the SAUNA PĆĆLLE (Sauna On) button, when pushed it sets power to zero but again when V5 or V4 are updated and then the V4 automatic calculation is reactivated.
Iād remove the Blynk code from the device and send it MQTT commands from Node-Red, and send back confirmations via MQTT.
All Blynk app commands from/to the app would go into Node-Red and be converted into MQTT messages.
Iāve spent the whole day fiddling with my HVAC HRV (heat recovery ventilation) unit control, so let me chime in with my solution.
as @PeteKnight suggested, itās best to keep the entire logic on the node-red side and make the MCU (NodeMCU) a pure MQTT client with some hooks on certain MQTT topics.
After it switches stuff, make it report back by publishing another message.
I personally use 2 separate topics [1]:
cmnd/{room}/{appliance}/{action} - for sending the commands
stat/{room}/{appliance}/{action} - for state reporting
I havenāt incorporated a CO2 sensor yet (btw Iād like to see your hw setup), but I made 2 automatic profiles (based on the time of the day) triggered by node-redcron node [1].
The strategy I came up with on forcing the manual setting is to define an extra virtual pin and treat it as a ālockā [2].
The cron flow then simply checks whether the lock is set before the automatic profile kicks in.
This can be further extended on the node-red side, by some simple timer, which would release the lock after expiration, etc.
I should probably have mentioned earlier that I donāt let my HVAC unit run in Auto mode.
If Iām in heating mode then I set my aircon to maximum temperature, then use a separate temperature sensor to decide when to put the aircon into idle mode (this keeps the vents open and fan running, but stops the heating process).
So, all Iām really doing is setting a target temperature for my logic control system and controlling the HVAC as needed.
My heating system also uses wall mounted electric panel heaters, which add some thermal mass to the process which helps to balance out the peaks and troughs when the aircon heating kicks in and drops out.
I was originally using the HVAC set to my target temperature, and controlling the panel heaters with my temperature sensor. The problem with this approach was that the HVAC and my temperature sensor were working differently - sensing the temperature differently and having a different hysteresis profile. This was what prompted the move to a single way of controlling all of the devices in a joined-up way.
I guess my system is neither full HVAC as it only contains roof fan to change air. So iVAC might be Better. The house is filled with several different ( printed my self on 3D printr boxes) , but main ingredients are same NodeMCU + DHT11 sensor + MH-Z14A CO2 sensors. They connect to Thingsboard mainly and send also MQTT messages to local Mosquitto server. Screens showing house data are on tablets showing Thingsboard.io screens.
hey @Soiski, thanks for the details on your project, I really like and is really close to what iām trying to achieve. I just started with a MQ135 with using some libs I found lying around github. Anyway I could get consistent air quality measurements so far (comparing to my off-shelf air quality monitor), so I havenāt incorporated the sensor readings into HRU control yet.
hereās my flow exported to JSON, hopefully youāll be able to load it.
It might require some additional plugins to be installed:
cron
node-red-contrib-blynk-api
node-red-contrib-blynk-ws
You should be able to get them installed straight from the UI (menu->manage pallette->install).
The bottom flow is what youāre probably interested in - reading from the left itās:
the cron node (time-based trigger) -> lock_check (to see if lock [V6 ping] is set) -> function node to send a proper value down the flow -> [publish the value to the appropariate topic] && delay node (to simply wait for the further execution for some time -> trigger node (which sends valu ā1ā to the mqtt node and contains implicit timer which sends another value (0) after certain period of time.
my MCU contains only Adafruit_MQTT_Client code with the radio module library code (that directly sends commands to my HRU) - no Blynk library is used now.
The whole Blynk integration (virtual pin states, virtual pin triggering) is done in the node-red
Thanks to Roman and Pete, whom pointed me to correct direction.
The final (and working) outcome looks like this where all calculations are done in Node-Red and only one (Power) value is feeded to NodeMCU to controll the TriAC. Key point as I was not using any ālockā was to get the Function (test Variables) running correctly.
Roman / Pete , One question though more. Seems that the Debug screen is constantly now showing that the BLYNK hardware is not on line; " DEVICE_NOT_IN_NETWORK" (as the Blynk is not running on it). Do I just forget it or ā¦
Glad you got it all working!
I donāt know where the " DEVICE_NOT_IN_NETWORK" is coming from.
I did a really small test on my node-red server and as long as any of the blynk ws nodes is configured to use a valid token (defined inside blynk app), it is auto-connected as soon as I deploy the flow and keeps the virtual device alive (itās not marked as offline in the android app).
I tried to experiment with some bridge nodes too, but i just wasnāt able to replicate the state youāre mentioning.
Can you perhaps figure out which exact node generates that warning and post its configuration details? good luck!
Iām guessing that you have connection type set-up thatās invalid.
This might be a connection to an MQTT server or to Blynk (the ones that you see when you choose from a drop down list of connections) that youāre not using, but which has invalid data in it.