blowerRPM airflowCFM coilTemp guages flickering

[ac-haynes]

After connecting the serial interface via IP, and seeing all the data flowing, I did not get any RPM/CFM/coilTemps in the UI.

I edited the af0fc153.js;

-  c.SrcClass.match(/(Furnace|FanCoil)/) 
+   c.SrcClass.match(/(IndoorUnit2)/) 

- c.SrcClass.match(/HeatPump/) 
+ c.SrcClass.match(/OutdoorUnit/) 

and public/app/scripts/controllers/main.js:
if (frame.SrcClass.match(/HeatPump/)) { to if (frame.SrcClass.match(/OutdoorUnit/)) {

and if (frame.SrcClass.match(/(Furnace|FanCoil)/)) { to if (frame.SrcClass.match(/(IndoorUnit2)/)) {

to line up with what I see in the Serial page's Device column.

but now I get the following weird behaviors

12ad8ede.vendor.js:5 Error: [ngModel:nonassign] Expression 'carbus.airflowCFM || status.idu[0].cfm[0]' is non-assignable. Element: <ng-dial-gauge title="Airflow" units="CFM" border-width="0" bar-color="#00FF00" bar-color-end="#FF0000" scale-min="0" scale-max="{{systems.config[0].systemCFM[0]}}" bar-width="10" ng-model="carbus.airflowCFM || status.idu[0].cfm[0]" class="ng-pristine ng-untouched ng-valid ng-isolate-scope">
https://errors.angularjs.org/1.8.2/ngModel/nonassign?p0=carbus.airflowCFM%20%7C%7C%20status.idu%5B0%5D.cfm%5B0%5D&p1=%3Cng-dial-gauge%20title%3D%22Airflow%22%20units%3D%22CFM%22%20border-width%3D%220%22%20bar-color%3D%22%2300FF00%22%20bar-color-end%3D%22%23FF0000%22%20scale-min%3D%220%22%20scale-max%3D%22%7B%7Bsystems.config%5B0%5D.systemCFM%5B0%5D%7D%7D%22%20bar-width%3D%2210%22%20ng-model%3D%22carbus.airflowCFM%20%7C%7C%20status.idu%5B0%5D.cfm%5B0%5D%22%20class%3D%22ng-pristine%20ng-untouched%20ng-valid%20ng-isolate-scope%22%3E
    at 12ad8ede.vendor.js:3:27190
    at Object.$$initGetterSetters (12ad8ede.vendor.js:8:27754)
    at Object.pre (12ad8ede.vendor.js:9:1001)
    at 12ad8ede.vendor.js:4:821
    at Ca (12ad8ede.vendor.js:5:10257)
    at o (12ad8ede.vendor.js:5:1679)
    at g (12ad8ede.vendor.js:4:29500)
    at g (12ad8ede.vendor.js:4:29517)
    at 12ad8ede.vendor.js:4:29017
    at 12ad8ede.vendor.js:5:41 '<ng-dial-gauge title="Airflow" units="CFM" border-width="0" bar-color="#00FF00" bar-color-end="#FF0000" scale-min="0" scale-max="{{systems.config[0].systemCFM[0]}}" bar-width="10" ng-model="carbus.airflowCFM || status.idu[0].cfm[0]" class="ng-pristine ng-untouched ng-valid ng-isolate-scope">' 

and the UI gives me a nice little dance (gif);

Thermostat SYSTXCCITC01-A Fan Coil FE4ANF005 Heat Pump 25HNB542A00310 Zone Board SYSTXCC4ZC01

Probably can turn this into a feature request after. Ability to specify the device names in the docker config. Or how can I change it on my thermostat?

[nebulous]

We obviously need a better way to reliably define/add different register locations in the serial stream(I've been resisting writing a one-off means to do this because I have to think there must exist some standard stream definition/specification format, but I've thusfar not found it) - and there's a semi-baked branch to do so floating around, but getting to your immediate problem, you'll have better luck by changing the input js files (see /public/app/script/*) then either running in development mode, or running a grunt build to generate the shrunken/minified versions.

[ac-haynes]

The values are correct, it's the popping into and out of existence that's the problem, and I can't tell why that's happening as I know just enough about dev to know to stay away code. It feels like it's picking up the correct value, the nulling when the next stream entry passes regardless of if it matches the Address

[dulitz]

@nebulous : pretty sure there is no "standard format" that is documented publicly -- you could try to convince a Carrier insider to spill an internal doc. There are substantial differences between the data transmitted by different models of furnace and heat pump.

But that's not related to this issue as the data is being parsed correctly, just not consistently. (Or perhaps it isn't persisted after being parsed -- sorry to be of no help with the perl.)

[nebulous]

@dulitz - yeah I didn't mean documentation from Carrier on the protocol - I'm sure that won't happen, I meant a standard means for documenting binary protocols in general. Something which could feed a parser generator. I could of course invent one, but it seems like something to define a binary serial protocol grammar should already exist - like Antlr/lex but for streams. Maybe Spicy could do... 🤔

[dulitz]

This isn't a tokenization/grammar issue, so flex etc. won't be so helpful. It's field parsing, more like protocol buffers or many other wire protocols that have existed over the years.

Take a look at https://github.com/dulitz/finitude/blob/master/finitude/registers.py which has a comprehensive parser Field.parse() for all the field types used in this protocol. Not complicated at all. Heck one could probably write some Python to process the REGISTER_INFO dictionary and emit Perl code that, when run, parses each register. :)

[ac-haynes]

Confirmed working with latest image! Amazing turnaround! Thanks!

[ac-haynes]

Been trying to scrap this info to store it in HA for longterm trend analyses and can't seem to find a json uri with the rpm cfm and coil temps I know of status.json, energy.json And the /api/config lists some blowerActualCFM":[{}],"blowerCoolingCFM":[{}],"blowerHeatingCFM":[{}],"blowerPower":[{}],"blowerSpeed":["916"],"calcMinCFM":["373"]," but blowerSpeed never changes Same is true for /systems.json

[nebulous]

Infinitude gets those values from the serial stream, not as XML(or json) from the thermostat. That said, in my firmware version/device combo at least, idu_status.json and odu_status.json have some of the values you're looking for.

[ac-haynes]

Thanks! Are you values accurate?

Doesn't look like the values are changing or accurate for me. {"idu_status":[{"opstat":["off"],"statpress":["0.42"],"lockoutactive":["off"],"version":"1.7","blwrpm":["914"],"coiltemp":["invalid"],"idutype":["fancoilelectric"],"lockouttime":["off"],"iducfm":["1225"],"lat":["invalid"],"inducerrpm":["na"],"pwmblower":["off"]}]}

statpress, blwrpmand iducfmare never changing

Also, is there a list of all the endpoint uri?

[nebulous]

The values should be accurate, but are unlikely to be timely. We're not able to tell the thermostat to publish them, so are reliant on whatever its default cadence is - probably expressed in hours, not minutes. Using the serial stream bypasses that lag, but also isn't readily available as json.

/api/state_keys should return a list of transactions/things the 'stat has published.

On my lengthy list of todos is configuration to publish values from Infinitude to MQTT topics, initially for situations like this, but eventually have Infinitude monitor topics as well to conform to the climate.mqtt interface.

What I'm excited about at present however is finally getting control of the thermostat via serial, so my free tuits are probably going to be spent on getting an esphome implementation of rs485 control.

[dulitz]

Blower speed etc. are pushed onto the bus every few seconds. My guess is his unit uses different registers for blower speed.

On Tue, Nov 15, 2022 at 9:41 AM nebulous @.***> wrote:

I the values should be accurate, but are unlikely to be timely. We're not able to tell the thermostat to publish them, so are reliant on whatever its default cadence is - probably expressed in hours, not minutes. Using the serial stream bypasses that lag, but also isn't readily available as json.

/api/state_keys should return a list of transactions/things the 'stat has published.

On my lengthy list of todos is configuration to publish values from Infinitude to MQTT topics, initially for situations like this, but eventually have Infinitude monitor topics as well to conform to the climate.mqtt https://www.home-assistant.io/integrations/climate.mqtt/ interface.

What I'm excited about at present however is finally getting control of the thermostat via serial, so my free tuits are probably going to be spent on getting an esphome implementation of rs485 control.

— Reply to this email directly, view it on GitHub https://github.com/nebulous/infinitude/issues/154#issuecomment-1315658853, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVWYJPWIKTYBCPTVDCVPM3WIPDNHANCNFSM6AAAAAARNQOWBY . You are receiving this because you were mentioned.Message ID: @.***>

[ac-haynes]

My thermostat (SYSTXCCITC01-A) has a daily test that runs at 1pm (ducthour) and updates idu_status and odu_status 15 minutes later. Confirmed by looking at the .dat files So bizarre because the display also updates every 10 seconds the statpress, blwrpm and iducfm but they never make it off the thermostat

@dulitz what do you have? Fan Coil: FE4ANF005L00ABAA HP: 25HNB542A00310