Hi
I’ve continued trying to integrate Cortex HVACs into my HA, with some success.
My goal is to have day-to-day HVAC functions in an HA dashboard so that I don’t RDP into Cortex to:
- check which HVAC zone has just caused the boiler to spark up
- disable the HVAC temporarily – e.g. if I don’t want it the kitchen zone on if I know I’ve got the back door wide open for an extended time
- see a zones current set point, whether it’s following occupied/unoccupied, delta between measured and set-point or measured and outside etc,.
- how long a zone has been on & when it’s (currently) due to go off
I’ve been using the Node-RED integration between Cortex and HA as I find that a quick way to “prototype” the interaction - easy to debug & update. I realise that’s going in the “wrong direction” for an eventual HA integration but I’m seeing it a prototype of what would need to be translated to an integration in python “later”.
My progress so far gives me a dashboard table as below:
Currently separate buttons allow me to toggle each zone’s Mode between ‘heating’ and ‘off’ (I don’t have any cooling) and option to trigger it on for the run-on period (as set in cortex). I’m intending to merge these into the grid so it’d be press the appropriate bit of change/trigger it. Also a the entity icon etc,.
Behind the dashboard presentation it’s all based on an ‘HVAC’ binary sensor with the entity state being whether the HVAC is on (heating) or off. I’ve relied mostly on everything being event-driven out of Cortex:
- Cortex HVAC object are configured as normal
- The HVAC Stage Change is connected to a WebClient item
- The WebClient item builds a POST to HA/Node-RED with all the useful info as json payload
- Node-RED:
- receives it
- unpacks the json
- does some conversions (e.g. the value ‘100’ if HVAC is ‘on’ to logic true etc),
- calculates the Current, Above Setpoint and Outside Deltas
- adds a ‘Friendly Name’
- packs all except the State/Value as attributes of the Entity
- maps everything to the right HA entity (based on a per-HVAC string in the json)
Example WebClient item:
[ only the zone name and HVAC object name in the payload are different for each HVAC ]
This is all Cortex → HA. What about HA → Cortex?
In the return path (e.g. to change the Mode or request heating for a run-on period) I’m using templated YML to send a request to Cortex, templating the Cortex Object ID, Port and Value.
To be consistent I should re-implement this in Node-RED, but its working as-is and in any case, these would need to be pythoned in any proper integration.
As these HA → Cortex seemed to ALWAYS return a “200 OK” confirming the request but regardless of the outcome, and with no payload, if I need feedback e.g. to confirm the new state or mode of the HVAC object, I found it’s possible to prod the WebClient Object, with a Port number specific to the WebClient Item and I’d then get (an updated) state info (which goes through the Node-RED stuff above, updating the HA entity…
Just like @Jonaz80 noted somewhere, the WebClient items don’t seem to be able to identify the triggering Object, and the json I’m using references the individual Object’s connections, so these are tediously created one-per-HVAC. In Node-RED the binary_sensor node is similar in that which most of the config is agnostic to the specific binary_sensor, the basic config of the node has a hard-defined entity name that cannot be taken from the incoming msg variable. So these are similarly near-identical duplicates (Grrrrrr) with a switch node diverting the incoming call from Cortex based on the ‘per-HVAC string in the json’.
(if only this could be replaced by a single binary_sensor object, based on an element in the msg)
There’s places where I’m mapping between Cortex and HA identifiers. Currently they are all text-based, including the string in the json which is only used in the WebClient Item and the switch in the Node-RED above - ie it’s neither a Cortex or HA string. In the HA->Cortex YAML I’ve referencing the HVAC object to act upon based on the Cortex ObjectID. I’ve realised that I should probably replace the ‘string in the json’ with the Object ID and then include that as another attribute in the HA Entity … then if you trigger an action (mode / run-on), in the HA automation rather than ANOTHER mapping (from HA Entity to Cortex Object ID), it would just retrieve the Cortex Object ID from the triggering HA Entity attribute… (if my description makes any sense!)
Anyway… My next target is to get room occupancy states into HA. I’ve got Cortex sending movement info, and HA pushing additional PIR data into Cortex, but not yet got Cortex’s Occupancy (instant or delayed, with timeouts etc) back to HA.
) .
