Replies: 5 comments 4 replies
-
|
A little update here, I used an absurdly tiny Xiao ESP32S3 to connect to Dallas DS18B20 waterproof temp sensors, and the hardware UART for CN105. It was a tight fit on the board but fits fine. The board has poor Wifi performance for some reason so I'm hesitating to actually recommend it yet, though I have it working now. I threaded the sensor cables through the unit so one sits on top of the intake grate, and one is threaded into the middle of the outlet grate. I like these sensors because they respond very quickly, and the smooth waterproof package doesn't easily get gummed up with dust or dirt. With two intake sensors and my CFM sensor, I can calculate the heating power. I calculate it in kW, and then convert to BTU/hr because I'm a yankee and we just like causing problems. I'm grabbing air density from my weather station, but picking a local average would be totally reasonable. Do check by altitude however, at sea level density is around 1.22 kg/m^3, but at my 5300ft elevation it is only 1.03 kg/m^3. I'd be 20% off if I used a generic number! sensor:
- platform: dallas_temp
address: 0x8b00000003eba528
name: "Intake Temperature"
id: intake_temp
unit_of_measurement: "°C"
device_class: "temperature"
state_class: "measurement"
update_interval: 2s
filters:
throttle_average: 6s
- platform: dallas_temp
address: 0x8c00000003136528
name: "Outlet Temperature"
id: outlet_temp
unit_of_measurement: "°C"
device_class: "temperature"
state_class: "measurement"
update_interval: 2s
filters:
throttle_average: 6s
- platform: template
name: "Delta T"
id: delta_t
lambda: |-
// Initialize variables
// airflow rate in m^3/sec, converted from CFM
float flow = id(fan_cfm).state * 0.000471947;
// Specific capacity of air at STC, in kJ/kg*K
float capacity = 1.005;
// DeltaT in degrees K
float delta_t = (id(outlet_temp).state - id(intake_temp).state);
// Air density in kg/m^3. 1.225 at sea level.
float density = id(air_density).state;
float power = 0;
// Calculate the heating or cooling power, in kW
power = delta_t * flow * density * capacity;
// Convert to BTU/hr for yankees
power = power * 3142;
// Update the thermal_power sensor and return the deltaT
id(thermal_power).publish_state(power);
return delta_t;
update_interval: 6s
state_class: "measurement"
- platform: template
name: "Thermal Power"
id: thermal_power
unit_of_measurement: "BTU/hr"
state_class: "measurement"
update_interval: never
filters:
- exponential_moving_average:
alpha: 0.1
send_every: 4
- platform: homeassistant
name: Air Density
id: air_density
entity_id: sensor.st_00086672_air_density
internal: trueThis gives some useful values: Interesting that intake temperature drops noticeably during call for heat as the fan starts pulling fresher interior air. 
Thermal power ranges are pretty realistic based on the max outputs of the unit. Hitting a delta T of 22 to 24 C, which feels good as well though I haven't confirmed the specs. |
Beta Was this translation helpful? Give feedback.
-
|
Photo of my abomination:
Sensor locations: Outlet: Intake: |
Beta Was this translation helpful? Give feedback.
-
|
Maybe these help; MSZ-RW25VG MSZ-LN25VG2 and MSZ-LN35VG2 The first has speed names from this integration, the second from geoffdavies' old. |
Beta Was this translation helpful? Give feedback.
-
|
Where do you get the CFM values from? Are those also measured, or from some documentation? Also, this is cool-as-shit!! |
Beta Was this translation helpful? Give feedback.
-
|
From the workshop manuals. I suspect i have the speeds and flowrates wrong still. I het too good COP values. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, here's the values for the MSZ-FH09NA series: 
I assume so far this is all for heating, not cooling? Or at least I'm not sure how you'd determine which of the wet/dry cooling numbers you'd use. I assume the fan mode names aren't the relevant things that it's just a mapping to the values the protocol parser defines, yes? The names in the above screenshot look a lot more reasonable than "Gentle" or "Moderate" vs "Medium" 😆 but maybe those names came from the docs somewhere too? |
Beta Was this translation helpful? Give feedback.
-
|
So far I'm just looking at heating. I have a few months yet before I have to worry about cooling. ;) The difference in Cooling Dry and Cooling Wet seems to just be based on the density of the air. I don't know what humidity values they are using for Dry and Wet, but wet air has more mass, and thus a lower CFM for the same fan power. The difference between Heating Dry and Cooling Dry appears to be due to slightly different fan speed setpoints, though I don't know why they do that. For instance, the smaller GL units (6, 9 and 12k), the fan speeds are identical except for Super High, which varies by 20 cfm inexplicably:
The larger units (15, 18 and 24k) are even weirder, the fan CFM values vary quite a bit between Heating and Cooling, but only by small magnitudes, and without a clear pattern.
Ultimately I think it doesn't make a giant difference, if what you are trying to do is look for a performance trend over time (consistently dropping max delta T over time could mean a refrigerant leak). For the units with bigger variations, I suppose my JSON could have a Cool and Heat mode list and the lookup pulls from the current operating mode as well. The dry/wet variation is probably even less important to worry about, but you could go crazy and use the humidity value from your remote room sensor to dynamically adjust the CFM based on a density scaling factor. I think the only reason to do that would be for our own amusement. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the context, I'm definitely interested in the high level take, so you're right that maybe the wet vs dry cooling doesn't matter. |
Beta Was this translation helpful? Give feedback.
-
|
I think we are getting pretty good results here, with the biggest uncertainty being the CFM values, since we don't really have a way to measure those on a minisplit. With an ECM motor I have reason to believe that the CFMs should be quite close to the specified values as long as the system is fairly clean, but I'm still unsure if I'm mapping the right fan speed to the right mode. Here is a shot of my GL12NA Kitchen unit's measured BTU/hr, compared to the calculation of BTU/hr I make for the entire heatpump (with 3 indoor heads, 2 x 12k and 1 x 18k). If all units were calling for the same heat at the same time, the Kitchen would be 28% of the load, but of course they aren't all calling for heat at the same time, and I don't have temp measurements on the other two heads yet. But from these numbers, my measurements look to be pretty close to my calculated values.
|
Beta Was this translation helpful? Give feedback.
-
I'm working on a little project to map the expected fan CFM value to the STAGE sensor in order to get a reasonable guess of the actual running CFM of a ductless unit. I'm going to capture my notes here to see if anything useful comes of it.
Testing first on an MSZ-GL18NA (pretty common indoor unit), here is the value mapping I'm seeing:
Of note here is that GENTLE and LOW seem ambiguous. When running in "auto" fan mode, I see both show up, with GENTLE seeming to be a higher output mode. However, if I use the remote I can only get LOW, and if I use the climate fan_mode of low then I get GENTLE.
The submittal for this unit gives 5 values for heating CFMs, but it isn't clear how they map to the apparently 6 distinct modes my unit will take on. Maybe "DIFFUSE" doesn't count because it can't be used while in heating mode (my unit will let me set "quiet", but will force the fan stage to LOW):
This is a mostly-functional lookup table - you have to define
modelin your substitutions, save the yaml below to a file atesphome/common/fanspeeds.yamland add as a package with:Fan speed lookups:
This creates a text sensor with the contents set to a JSON string of models (just the three I own), and their mapping from STAGE to CFM, and a text sensor with your model number. Every 5 seconds, the template looks up the model and CFM value, and updates the Fan CFM sensor. It is filtered with a
deltafilter, meaning that while it is internally updating every 5 seconds, it will only send a value to HA when the value actually changes (more than 1, in this case).Me playing with my fan speeds to try to figure out what is going on:
Eventual hope would be to make a big JSON with all the common models, and possibly include it directly in this component so your CFMs would be populated if you had a supported model. Right now just playing around with the data.
Beta Was this translation helpful? Give feedback.
All reactions