Posted by: @editor

↑

maybe you could arrange and condense it into an article (word count is up to you) and it could be posted on the main site as a reference article. Let me know.

Thanks, I will think about it, but first thoughts are that it will sit quite comfortably in the Beginner's Guide thread, and the thread provides context and background. As a standalone article, I would need to add some of that background, and the end result could be a rather long article, all the more so as given it is a Beginner's Guide I do tend to be rather verbose! But better to include too much detail than miss out something important.

Posted by: @filipe

↑

Well done! I guess if you create HA sensors using this data you are home and dry with nice graphs. If you want the input power there are electric meters with Modbus interface. 

Thanks. Whether to carry on using HA is the 64m dollar question I am asking myself right now. The pros (for HA) are that it does produce visually attractive graphs (strictly speaking, that is not true, HA's own charts are horrible, its the History Explorer Card 'resource' (more pointless HA jargon) that produces those attractive charts) and - well, and what? The visually attractive charts produced by a third party add-on are the only plus point for HA. On the minus side, we have unassailable jargon, pointless complexity, code and guides written by sadists, forum bullies, and probably the most minus point of all, HA's willingness to destroy its own data. You can probably get a sense of where I am heading with all this...

Posted by: @mphb

↑

There is a big chance that you have already seen it, but it would have been a pity if you hadn't.

Thanks, and yes, without @derek-m's help I would have gone mad ages ago, and probably concluded that the answer to everything is 42: LWT 42, DHW tank temp 42, COP, 4.2, keep it nice and simple.

I have seen the HA forum thread (another HA minus point, it's forum pages are a PITA to navigate) but not the very recent github addition. Again, I think they are probably over-complicating it, you don't need ESP and HA to get the data, you can do it with a few lines of python code that even I can write, and crucially, understand what I have written. The github Midea-heat-pump-ESPHome/heatpump.yaml file on the other hand has a staggering 2441 lines of code, way way way to complex. Spreadsheets charts don't have to be horrible, even if often the default ones are, and if you want really snazzy charts then there are things like R, but programming R is not for the faint-hearted. 

There's quite a lot not to like about this chart, but still worth posting as proof of concept. I've had the python code running over three hours, logging data every minute (interval is set in seconds, just one number to change) to a csv file, which I have now used for a quick and messy plot: 

The complete set of data is:

datetime	self-explanatory
on_off_bin	the binary representation of register address 0 which contains what is on/off data
htg_on_off	failed attempt to get wheather space heating is on or off bit
dhw_on_off	failed attempt to get wheather dhw heating is on or off bit
RWT	        RWT in degrees C
LWT	       LWT in degrees C
ambient	        ambient (outdoor) temp in degrees
room_temp	no use as wired controller is slow cooking in the airing cupboard
dhw_temp	actual tank temp in degrees C
amps_in	        amps in to the compressor 
volts_in	  volts in to the compressor
capacity	  probably nominal output, also known in this parish as Hendra's Headroom
setLWT	       set LWT is degrees C
flowrate	 flow rate in m^3/h
ability	       mideaspeak for current actual output in kW?
energy_in	total (lifetime) energy in (kWh)
energy_out     total (lifetime) energy out (kWh)

I chose the start and end time to include 1300 to 1400, which is when the DHW is set to come on by a timer, and made sure the tank actual temp was low enough to trigger DHW heating (< 40 degrees) when 1300 came around.

The un-plotted large number values, volts_in and total energy in and out are all credible, and agree with the same values reported elsewhere (in app/HA/on the wired controller).

Some lines from the csv file covering the period when the dhw heating kicked in:

datetime,on_off_bin,htg_on_off,dhw_on_off,RWT,LWT,ambient,room_temp,dhw_temp,amps_in,volts_in,capacity,setLWT,flowrate,ability,energy_in,energy_out
2023-03-20T12:50:09,10,1,0,36,39,11,25,34,5,243,14,39,1.34,5.23,11313,30802
2023-03-20T12:51:09,10,1,0,36,39,11,25,31,5,245,14,39,1.36,5.34,11313,30802
2023-03-20T12:52:09,10,1,0,36,39,11,25,27,5,244,14,39,1.36,5.34,11313,30802
2023-03-20T12:53:09,10,1,0,36,40,11,25,26,5,245,14,39,1.36,5.11,11313,30802
2023-03-20T12:54:09,10,1,0,36,40,11,25,25,5,245,14,39,1.35,5,11313,30802
2023-03-20T12:55:09,10,1,0,37,40,11,25,25,5,245,14,39,1.36,5,11313,30803
2023-03-20T12:56:09,10,1,0,37,40,11,25,25,5,245,14,39,1.36,4.88,11313,30803
2023-03-20T12:57:09,10,1,0,37,40,11,25,25,5,244,14,39,1.36,5,11313,30803
2023-03-20T12:58:09,10,1,0,37,40,11,25,25,5,244,14,39,1.38,5.11,11313,30803
2023-03-20T12:59:09,10,1,0,37,40,11,25,25,5,244,14,39,1.36,5.34,11313,30803
2023-03-20T13:00:09,10,1,0,37,41,11,25,25,5,244,14,39,1.35,5.58,11313,30803
2023-03-20T13:01:09,110,1,0,31,40,11,25,25,3,243,14,40,1.39,15.58,11313,30803
2023-03-20T13:02:09,110,1,0,28,30,11,25,26,3,243,14,40,1.46,3.48,11313,30803
2023-03-20T13:03:09,110,1,0,25,30,11,25,26,3,244,14,40,1.42,9.07,11313,30804
2023-03-20T13:04:09,110,1,0,28,32,11,25,27,5,243,14,40,1.44,8.02,11313,30804
2023-03-20T13:05:09,110,1,0,28,33,11,25,27,5,243,14,40,1.46,8.72,11313,30804
2023-03-20T13:06:09,110,1,0,29,34,10,25,28,5,241,14,42,1.43,8.72,11313,30804
2023-03-20T13:07:09,110,1,0,30,35,11,25,29,5,243,14,40,1.43,8.25,11313,30804
2023-03-20T13:08:10,110,1,0,31,37,11,25,29,6,243,14,40,1.43,9.07,11313,30804
2023-03-20T13:09:10,110,1,0,32,38,11,25,30,6,242,14,40,1.42,9.3,11313,30804
2023-03-20T13:10:10,110,1,0,33,39,11,25,31,6,242,14,40,1.45,9.53,11313,30804

The on_off_bin column (column 2) does reflect what is in the register:

bit 0 (right-most bit) is air con ('cooling'?) - whatever it is, it is off (0) 

bit 1 (middle bit) is floor heating which I take to be space heating - it is on throughout, which it shouldn't be (DHW takes precedence when on) 

bit 2 (left most bit) is DHW heating - correctly comes on at 13:01 (and went off an hour later).

This (using bit 2) would be enough info to allow allocation of energy used to space/dhw heating were it not for the fact that in the period from 1345 (tank now at set temp) to 1400 (DHW off on timer) the heating came on (about 1351, you can see it in the chart, where the RWT/LWT start to rise again). If I use bit 2 = 1 to mean DHW use, then that space heating energy would be wrong allocated to DHW use. I think the problem here is that the on/off status is on/off 'at the wall' status, not whether it is actually running (can be 'on at the wall' but not heating because thermostat is satisfied). There is also a question about why the space heating bit remained on when it was off, which may be another 'on at the wall' but not actually running artefact.  

The chart also shows some cycling on the left hand side (no amps in, no power ('ability') out), maybe I need to lower the set LWT at the warmer ambient end of my weather comp curve.

This also raises the question of how the unit regulates its output. My Midea unit almost always has flow rates in a very narrow range, so it is not that,  RWT/LWT delta t is usually around 5, so it's not that, which leaves only one other option: cycling. But maybe this is a mild weather phenomenon, maybe in colder weather it will regulate itself by varying flow rate or delta t. The things is, I now have the data to look into this.   

Lifetime COP is something under three (around 2.72). Not brilliant, and also partly suspect, COPs over shorter periods especially in milder weather have been > 3, sometimes even approaching 4.

I will need a few days to get this working on the mini PC (it's currently on my desktop) and then hopefully I can write it up in a useful format.

@cathoderay

Rather than looking at bits 1 and 2 in address register 0, to decide if you are heating DHW or CH, you could look at bit 4 in address register 129, which indicates the position of the 3-way valve SV1.

@derek-m - I've just realised that some of the modbus tables look almost the same but they are not. The manual I have has this for register address 0: 

which is subtly different to what I thought I had earlier, and, following your suggestion, this for register address 129: 

But as it is a multi bit address, how to get the relevant bit, and as it is binary, it will be 1 or 0, and how to know which means what? The code I used earlier was:

    on_off = instrument.read_register(0, 0)
    htg_on_off = (on_off >> 1) & 0x1
    dhw_on_off = (on_off >> 2) & 0x2

where 'instrument' is the 'object' representing the controller data and read_register(0, 0) is read_register(address, decimal places) with decimal places used when a number with decimals is stored as an integer eg if the value is stored as 42, then decimal places = 1 will convert it to 4.2). The bitwise operator lines were a stab in the dark that missed their mark...

I'm using the minimalmodbus python module, the documentation, which is marginally less sadistic than usual, is available here, but it doesn't really cover getting bits in a way that works.   

@derek-m - I've just run the code with

on_off = instrument.read_register(129, 0)

and got this as the binary output:

2023-03-20T18:33:26,10000001101000,0,2,41,46,10,25,47,6,242,14,42,1.32,7.79,11321,30832

as the bit numbers are zero based, bit 4 is in position five from the right:

10000001101000

but at the moment the space heating is on. Maybe I will have to wait until the DHW needs heating again, and observe how the binary output changes.

@derek-m - just realised I could set a higher tank set temp and override the timer to get the hot water heating to come on, which it did, confirmed by feeling the valve move (and by the valve manual lever movement limit) and the binary output changes as follows:

valve set to space heating:        10000001101000

Valve set to hot water heating:  10000000011000

Other bits have changed but so too has bit 4 in position 5 from the right. I can get that by getting a substring, which perhaps is the best way to do it, given that getting a substring is more intelligible than bitwise operators.

Using indexing with a negative (start counting from right hand end) number then if x = 1234 then x[-1] = 4 (but even this has it's own bit of pythonic  sadism: counting from the left is zero based, counting from the right is 1 based) but putting that aside, here we go:

>>> on_off = 10000001101000
>>> str(on_off)[-5]
'0'
>>> on_off = 10000000011000
>>> str(on_off)[-5]
'1'

etc 

Using the valve position still has an 'on at the wall but not in action' state, but combined with amps_in which can be a proxy for whether the compressor is running or not, it should allow correct allocation of energy use to either space heating or dhw heating.   

Posted by: @cathoderay

↑

@derek-m - I've just run the code with

on_off = instrument.read_register(129, 0)

and got this as the binary output:

2023-03-20T18:33:26,10000001101000,0,2,41,46,10,25,47,6,242,14,42,1.32,7.79,11321,30832

as the bit numbers are zero based, bit 4 is in position five from the right:

10000001101000

but at the moment the space heating is on. Maybe I will have to wait until the DHW needs heating again, and observe how the binary output changes.

 

You would need to use a mask to extract the required data. I'm not 100% certain about the Python syntax, but basically you need to & (AND) the data with 0x10, which should produce the following.

dhw_on = on_off & 0x10    # If bit 4 (position 5) is 1, then the result is true.

dhw_off = on_off & 0x10    # If bit 4 (position 5) is 0, then the result is false.

If my understanding is correct the & performs binary comparison, so if bit 4 is 1 in on_off, as it is in 0x10, then it passes the test. If bit 4 is 0, then it fails the test. You can further combine this output with a test to see if the compressor is running, should you desire to do so.

Posted by: @cathoderay

↑

@derek-m - just realised I could set a higher tank set temp and override the timer to get the hot water heating to come on, which it did, confirmed by feeling the valve move (and by the valve manual lever movement limit) and the binary output changes as follows:

valve set to space heating:        10000001101000

Valve set to hot water heating:  10000000011000

Other bits have changed but so too has bit 4 in position 5 from the right. I can get that by getting a substring, which perhaps is the best way to do it, given that getting a substring is more intelligible than bitwise operators.

Using indexing with a negative (start counting from right hand end) number then if x = 1234 then x[-1] = 4 (but even this has it's own bit of pythonic  sadism: counting from the left is zero based, counting from the right is 1 based) but putting that aside, here we go:

>>> on_off = 10000001101000
>>> str(on_off)[-5]
'0'
>>> on_off = 10000000011000
>>> str(on_off)[-5]
'1'

etc 

Using the valve position still has an 'on at the wall but not in action' state, but combined with amps_in which can be a proxy for whether the compressor is running or not, it should allow correct allocation of energy use to either space heating or dhw heating.   

Compressor On is bit 13 of address register 129, so you could possibly use the following:-

dhw_on = on_off & 0x2010    # If bit 4 is 1 and bit 13 is 1, then the result is true.

dhw_off = on_off & 0x2010    # If bit 4 is 0 or bit 13 is 0, then the result is false.

More comedy cr@p from HA: how do I run my python modbus script on the mini PC given HA's control freakery over what you can and can't do?

Apparently I need something called pyscript => binned as uninstallable. HA and pyscript documentation contradictory, worse than useless.

Apparently I need something called AppDaemon. I can tell you right now where this is going, File 13, somewhere the sun don't shine, anywhere as long it is not on my system:

"About: AppDaemon is a loosely coupled, multithreaded, sandboxed Python execution environment for writing automation apps for Home Assistant home automation software. It also provides a configurable dashboard (HADashboard) suitable for wall mounted tablets."

The only thing that got executed round here was AppDaemon.

From the forum:

"to run a python script, you just call the service:

service: python_script.testosc [ie service: folder.script]"

Result: 

"Configuration invalid!

Integration error: service - Integration 'service' not found."

This is a 100% typical HA t*rdfest... All I want to do is run my simple python script, and all HA wants to do is stop me. No doubt, all for my own good.

Several hours later:

I finally found a way, involves taking a sledge hammer to HA and opening up a remote SSH terminal connection that doesn't have all HA's 'this is for your own good' restrictions. Here is modbus_data.py (my script) running on the mini PC and printing output every six seconds on the screen:

bash-5.1# python modbus_data.py
2023-03-21T11:24:52,10000001101000,1,0,36,39,11,25,39,5,245,14,39,1.36,5.34,11343,30912
2023-03-21T11:24:58,10000001101000,1,0,36,39,11,25,39,5,245,14,39,1.36,5.34,11343,30912
2023-03-21T11:25:04,10000001101000,1,0,36,40,11,25,39,5,245,14,39,1.35,5.46,11343,30912
2023-03-21T11:25:10,10000001101000,1,0,36,40,11,25,39,5,244,14,39,1.35,5.46,11343,30912
2023-03-21T11:25:16,10000001101000,1,0,36,40,11,25,39,5,245,14,39,1.35,5.46,11343,30912
2023-03-21T11:25:22,10000001101000,1,0,36,40,11,25,39,5,245,14,39,1.35,5.46,11343,30912
2023-03-21T11:25:28,10000001101000,1,0,36,40,11,25,39,5,244,14,39,1.35,5.11,11343,30912
2023-03-21T11:25:34,10000001101000,1,0,36,40,11,25,39,5,245,14,39,1.35,5.11,11343,30912
2023-03-21T11:25:40,10000001101000,1,0,36,40,11,25,39,5,245,14,39,1.35,5.11,11343,30912
2023-03-21T11:25:46,10000001101000,1,0,36,40,11,25,39,5,245,14,39,1.35,5.23,11343,30912
2023-03-21T11:25:52,10000001101000,1,0,36,40,11,25,39,5,244,14,39,1.35,5.23,11343,30912
2023-03-21T11:25:58,10000001101000,1,0,36,40,11,25,39,5,245,14,39,1.35,5.23,11343,30912
2023-03-21T11:26:04,10000001101000,1,0,36,40,11,25,39,5,246,14,39,1.35,5.23,11343,30912
2023-03-21T11:26:10,10000001101000,1,0,36,40,11,25,39,5,245,14,39,1.35,5.11,11343,30912
2023-03-21T11:26:16,10000001101000,1,0,36,40,11,25,39,5,246,14,39,1.35,5.11,11343,30912
2023-03-21T11:26:22,10000001101000,1,0,36,40,11,25,39,5,245,14,39,1.35,5.11,11343,30912
2023-03-21T11:26:28,10000001101000,1,0,36,40,11,25,39,5,245,14,39,1.38,5.23,11343,30912
2023-03-21T11:26:34,10000001101000,1,0,36,40,11,25,39,5,244,14,39,1.38,5.23,11343,30912
2023-03-21T11:26:40,10000001101000,1,0,36,40,11,25,39,5,244,14,39,1.38,5.23,11343,30912 

@derek-m - I'm working on the bitwise stuff, just need to get my head round some basics. At the moment I am just using simple string extraction and 'if' tests. The 1,0 after the binary string in the above data are space heating and dhw heating, 1 = on, 0 = off. 

Rather than get tied down in bitwise stuff (which most people including me find baffling) I'm sticking with string extraction for now.

I already have one python script collecting data every minute and logging it to a csv file. Next step is to get hourly stats and this seems to be working.

Output from a script that extracts the last hours data and does some stats on it. Only 50 lines of code, many of which are print() statements. Hopefully self-explanatory:

===================== RESTART: Z:\modbus\modbus_hr_data.py =====================

Midea kWh in:
total energy in now: 11371
total energy in 60m ago: 11370
midea kWh in: 1

Calculated kWh in:
mean amps: 4.216666666666667
mean volts: 241.66666666666666
calc_kWh_in: 1.02

Midea kWh out:
total energy out now: 31015
total energy out 60m ago 31011
midea kWh out: 4

Calculated kWh out (assuming 10% glycol, specific heat 4.05):
mean flowrate m^3/h: 1.3413333333333333
mean flowrate litres/sec: 0.3725925925925926
mean delta t: 3.0
calc_kWh_out: 4.53

COPS:
midea_60m_COP: 4.0
calc_60m_COP: 4.44

>>>

I haven't bothered to round the intermediate variable decimal places, I'm not for a moment suggesting the data is that accurate, it is just a calculated value artefact.

COP is good because weather is mild.

@batalto - we may have cracked the Midea kWh integer mystery

@cathoderay it would seem it is as we expected. Rounding downwards makes the COP look much worse than it actually is and power use look higher. In essence we knew this was true anyway as my readings from the app and actual measured use don't match up in any meaningful way.

@batalto - the above is a one off reading, it will be interesting to see whether the Midea figures always round downwards once I have a series of readings. The key thing is the Midea figure appears always to be calculated from integers (the total energy figures) so the result is always an integer. My hunch is that it will always round downwards, because at any one moment in time, the current Midea total energy figure will for most of the time be lower than the true total energy figure, because it is in effect the floored current figure (true value 11371.5 becomes 11371 and stays that way until the true value get to 111372 and so on). But there is also this possibility:

         True        Midea
Now   11371.1   11371
Past   11370.5   11370
Diff           0.6          1

as well as

         True        Midea
Now   11371.5   11371
Past   11370.1   11370
Diff           1.4          1

ie it depends on the relative size of the decimal component. 

I'll post some data when I have it.