@cathoderay

It is quite simple really. Like decimal, binary can be represented in rows and columns.

Decimal.                   Binary.

Tens.  Units.            8's.  4's.  2's.  1's.

   0       0                   0     0     0      0

   0       1                   0     0     0      1

   0       2                   0     0     1      0

   0       3                   0     0     1      1

   0       4                   0     1     0      0

   0       5                   0     1     0      1

   0       6                   0     1     1      0

   0       7                   0     1     1      1

   0       8                   1     0     0      0

   0       9                   1     0     0      1

   1       0                   1     0     1      0

It could be that all you need to do is overwrite the 6 with 2 and the system may be reset.

If that does not work then I can explain how to manipulate binary data.

@derek-m - I am very wary of writing to any register until I am absolutely sure what I am writing to, hence the attempts to reliably read the data before writing anything. I absolutely do not want Ray Towers (located at a secret location somewhere south of the M4) ending up looking like this:

I've just run this in the python console on the two response strings in the minimalmodbus debug log:

>>> i = int("01030200023985", 16)
>>> i
284782101674373
>>> j = int("01030200063846", 16)
>>> j
284782101936198
>>> for n in range(0, 6):
	print((i>>n) & 1)

	
1
0
1
0
0
0
>>> for n in range(0, 6):
	print((j>>n) & 1)

	
0
1
1
0
0
0
>>> 

I seem to recall we had this problem of how to read these bit based registers before, and gave up, using the position of the three port valve as a proxy for whether the heat pump was in heating or DHW mode, and then discovered that too was a bit based register. Borrowing from that code I ran this in the script:

reg0 = instrument.read_register(0)

for i in range(1, 6):
    print("{:08b}".format(reg0)[-i])

and got the following, respectively, in heating and then DHW mode:

0
1
0
0
0

and 

0
1
1
0
0

ie this is the 2 and the 6, and furthermore the first one (heating on) looks right, bit 1 (in position (row) 2) is the heating bit, and the 1 in the second row = heating on, but the second one doesn't make sense, it 'says' both the heating (row 2) and DHW (row 3) are on (both have 1 rather than 0). 

My head is beginning to hurt... 

@cathoderay

Have a look at page 143 of the attached manual.

@derek-m - thanks. There are lots of versions of this table around, and they are all slightly different. Here's a scan of the same part of the table from the wired controller manual that came with my heat pump, so I presume it shows the correct information, and is the one I have been working from:

As you can see, the information I want is in bits 1 and 2 at register address 0, bit 1 being heating and bit 2 DHW, with value 0 = power off, value 1 = power on. I'm assuming it is read/write, I can either get the current state, or set a new state. At the moment I want to be sure that i really am addressing the right location, hence read only for now.

I also understand that the heat pump can only ever be in one mode at any one time. Thus heating on (and DHW off) in binary should be 0010 (which is 2 decimal) and DHW should be 0100 (which is 4 decimal) but what I get is 2 (0010) with heating on which is correct, but, with DHW on, I get 6 (0110) which seems wrong: both heating and DHW are on. But that's impossible...        

I finally found something in the minimalmodbus manual on how to read individual bits from a 16 bit register:

Reading individual bits from a 16-bit register

Some manufacturers use 16-bit registers to store individual boolean values (bits), so with a single read from a single address, 16 booleans could be retrieved. This is sometimes called a flag register.

You need to read the register as an integer, and then extract the bit you are interested in. For example to extract the third bit from right:

registervalue = instrument.read_register(4143)
is_my_bit_set = (registervalue & 0b0000000000000100) > 0

Adapting this code, with heating on and DHW off I got (the result comes back as a boolean value):

bit1=False
bit2=True
bit3=False
bit4=False
bit5=False

which, assuming True is 1 and False is 0, is correct, 00010 binary ie bit 2 (heating) and only bit 2 is on, but if I turn on the DHW, meaning the heating should be off, I get

bit1=False
bit2=True
bit3=True
bit4=False
bit5=False

which is the same result, 00110 binary or 6 decimal, the same result as using other methods, when it should be 00100 binary, decimal 4. ie bit 3 (DHW) and only bit 3 is on.

I'm beginning to wonder if this is a sort of bug in the Midea code: the register can have both the DHW and heating apparently on, but something else dictates that only one is in fact on. Go figure... 

Maybe it's the DHW PRIORITY setting, if it is on, which it is, then when both are on, DHW takes priority. 

Edit: for those interested in the technical implementation of the code and how it works:

The code:

registervalue = instrument.read_register(0)
print(f'bit0={(registervalue & 0b0000000000000000) > 0}')
print(f'bit1={(registervalue & 0b0000000000000001) > 0}')
print(f'bit2={(registervalue & 0b0000000000000010) > 0}')
print(f'bit3={(registervalue & 0b0000000000000100) > 0}')
print(f'bit4={(registervalue & 0b0000000000001000) > 0}')
print(f'bit5={(registervalue & 0b0000000000010000) > 0}')

registervalue comes back as 2 or 0b0000000000000010

bitwise & (AND) compares two numbers and returns a 1 when both numbers have 1 in same position:

bit2 line above has          0b0000000000000010
registervalue has            0b0000000000000010 

which returns 0000000000000010 which is > 0 and so evaluates to True

but for bit3 

bit3 line above has             0b0000000000000100
registervalue has               0b0000000000000010

which returns 0000000000000000 which is not > 0 and so evaluates to False

The coldest night of this heating season so far, briefly got down to 2 degrees outside and 16.4 inside, but by 0712 hours the IAT was back to 18 degrees:

Curiously, there were no defrost cycles to compromise performance, and the heat pump maintained a LWT in the high 40s for most of the recovery time.

Based on energy use before the setback, around 1.7 kWh per hour, the setback saved at least 10.2 kWh. During the recovery boost, which I shall define as the period during which the auto adapt script boosted the the WCC end points and the heat pump was on, ie the period 0300 to 0900:

2023-11-11T00:01:30,-1.6,57,35
2023-11-11T01:01:30,-1.9,57,35
2023-11-11T02:01:30,-2.3,58,36
2023-11-11T03:01:30,-2.6,58,36
2023-11-11T04:01:30,-1.9,57,35
2023-11-11T05:01:30,-1.4,57,35
2023-11-11T06:01:30,-1.4,57,35
2023-11-11T07:01:30,-1.1,57,35
2023-11-11T08:01:30,-1.0,57,35
2023-11-11T09:01:30,-0.8,56,34

(the above is the auto adapt log, hourly entries showing dateTtime, actual vs desired room temp difference (negative means actual was less that desired by the amount shown), left end of WCC set LWT, right end of WCC LWT, with 56,34 being the default, non-adapted settings, which the auto adapt script returned to at 0901), the heat pump used, based on the chart above around 2 kWh per hour, making a total recovery boost use of 12 kWh.

But given the prevailing conditions - ie OAT a bit lower than before the setback - we can say that without the boost it would have used at least 1.7 kWh per hour during the recovery boost period (based on what it used before the setback), or 10.2 kWh in total over the entire recovery boost period (it's the same as the amount saved because both periods are six hours). The extra energy used during the recovery boost was therefore 12 - 10.2 = 1.8 kWh.

Energy saved during setback:         10.2 kWh

Extra energy used during recovery:  1.8 kWh    

Total net saving:                             8.4 kWh   

Edit: corrected coldest night of the year to coldest night of this heating season

Tinkering with my Grant ASHP is beyond my technical abilities but I too noticed that last night was the coldest night of the season so far.

Here in West Oxon the temperature touched 2 deg C and in early morning as the ASHP came on for the UFH I noticed that it had frosted up. The first time this season.

Happily the pump cleared this quickly but frosting is when my electricity usage starts to climb rapidly. The outdoor humidity is 92%, not unusual here. But when it gets properly cold my ASHP can remain frosted up for hours. Clearly not a great design feature of the Grant ASHP.

Mike

Posted by: @mike-patrick

↑

frosting is when my electricity usage starts to climb rapidly. 

Same here when it gets below to around 5 degrees and below, which is why I am surprised I didn't have any defrost cycles last night.

Posted by: @mike-patrick

↑

But when it gets properly cold my ASHP can remain frosted up for hours. Clearly not a great design feature of the Grant ASHP.

Surely that should not happen? If it stays frosted up for hours it is never going to heat the house adequately. I don't know about the Grant controls, but maybe there are some changes you can make to reduce this. Others with Grant heat pumps might have some ideas.

Don't be too alarmed by the code that sometimes gets into my posts. It is only there for those who have an interest in these things, and to allow the excellent @derek-m to comment. But minor tinkering should within grasp for anyone who can program a timer. The problems are mostly fining out which buttons to press, and in what order. That's where this forum can be such a help. 

@jamespa

Hi James,

I would welcome your thoughts on the following.

Calculating the thermal energy output from heat emitters is fairly straightforward when the heat pump is running constantly, but of course this will not be the case when the heat pump starts to cycle at higher ambient air temperatures.

Whilst it is running the heat pump will be supplying more thermal energy than is required, so the output from the heat emitters will cause the IAT to increase. When the heat pump stops, the heat emitters obviously don't stop emitting thermal energy, but of course the electrical energy being supplied will have reduced quite considerably.

This leads to a somewhat grey area when it comes to calculating the actual thermal energy supplied in relation to the quantity of electrical energy consumed.

@derek-m and @jamespa - it might help if I clarify how I do the calculations.

The minute data has amps, volts, LWT, RWT and flow rate. I have assumed the specific heat capacity of the primary circuit fluid is 4.05 (10% glycol).

My code then calculates values based on the averages over the hour eg mean volts x mean amps for energy in, LWT/RWT x flow rate x specific heat for the energy out etc. I tried doing the calculations for each minute, and then summing them over the hour, using simple and more complex eg area under the curve type sums, but (unsurprisingly, when you consider what a mean is...) got the same results, so, being simple minded, I kept it simple.

These calculated values agree fairly well with the values derived from Midea's total lifetime energy in and out values. Here are the hourly values for the last 24 hours (the differences may come from rounding errors in the Midea total lifetime values):

datetime			midea_kWh_in			calc_kWh_in			midea_kWh_out		calc_kWh_out
2023-11-11T17:01:01		2				1.38				5				5.55
2023-11-11T18:01:00		2				1.62				5				5.96
2023-11-11T19:01:00		2				1.64				5				6.02
2023-11-11T20:01:00		2				2.04				6				6.43
2023-11-11T21:01:00		2				1.84				6				6.72
2023-11-11T22:01:00		0				0				0				0
2023-11-11T23:01:01		0				0				0				0
2023-11-12T00:01:00		0				0				0				0
2023-11-12T01:01:00		0				0				0				0
2023-11-12T02:01:00		0				0				0				0
2023-11-12T03:01:00		0				0				0				0.07
2023-11-12T04:01:01		2				1.85				8				8.16
2023-11-12T05:01:00		2				1.77				6				6.42
2023-11-12T06:01:00		1				1.74				6				6.1
2023-11-12T07:01:00		2				1.64				6				6.12
2023-11-12T08:01:00		2				1.97				7				6.92
2023-11-12T09:01:00		1				1.61				6				6.1
2023-11-12T10:01:01		2				1.34				5				5.2
2023-11-12T11:01:00		2				1.42				6				6.05
2023-11-12T12:01:00		1				1.26				5				5.12
2023-11-12T13:01:00		2				1.24				5				5.28
2023-11-12T14:01:00		2				1.6				7				6.6
2023-11-12T15:01:01		1				1.1				5				5.43
2023-11-12T16:01:00		1				0.91				4				4.48
Total			       31				27.97				103				108.73

Because the code does a reading every minute, minute by minute fluctuations get picked up eg when cycling is present (they would get lost in longer time frames). Sure there will be lag (catching up) effects, but I suspect they tend to cancel out (as in a bit of heat appears to overflow into a time when the compressor is off, and a bit of cold overflows into when the compressor is on). If you look at the above table, during the hour 0200-0300, the calc_kWh_out has magicked 0.07 kWh out of thin air (in fact almost certainly, literally out of thin air). But the amount is a tiny fraction of the daily total, and won't throw things out badly.

My calculations obviously estimate what the heat pump puts out into the primary circuit, not what the rads emit into the room, which will clearly be less.      

@derek-m 

Posted by: @derek-m

↑

Calculating the thermal energy output from heat emitters is fairly straightforward when the heat pump is running constantly, but of course this will not be the case when the heat pump starts to cycle at higher ambient air temperatures.

Whilst it is running the heat pump will be supplying more thermal energy than is required, so the output from the heat emitters will cause the IAT to increase. When the heat pump stops, the heat emitters obviously don't stop emitting thermal energy, but of course the electrical energy being supplied will have reduced quite considerably.

This leads to a somewhat grey area when it comes to calculating the actual thermal energy supplied in relation to the quantity of electrical energy consumed.

Hmm, needs some thought

I think this may be where it helps to distinguish mentally heat (a) demanded by the emitters from (b) heat supplied to the emitters.  My first thought (assuming a tolerably well insulated system) is that:

If the pump is cycling then the pump feedback loop will ensure that, averaged over a cycle, b=a.  I wouldn't want to try to model it during a cycle because that's going to depend on too many factors, but averaged over a cycle it should be what happens.

Of course that then begs the question,  how much heat is demanded by the emitters, which is uncertain because we don't know the emitter temperature due to the fact that when the hp is off the flow temperature will drop back.  This might  depend on how the heat pump cycling control loop works.  It might crudely and simply keep the flow temperature within bounds set by user controlled hysteresis variables, or it might time average the measured flow temperature so that on average it equals the target in the wc curve.  Or it might be more sophisticated still and take account of the emitter characteristic (eg whether its ufh with an exponent of 1, or rads with an exponent of 1.3) and time average taking that into account.  We don't know, but if it does it with tolerable accuracy then it should adjust things so that the amount of energy delivered is as if the emitters were kept constantly at the temperature demanded by the wc curve, for the prevailing oat.

Thus in summary I think I would assume, until experiment proves differently,  that the energy supplied to the emitters when the pump is cycling is the same as that which would be supplied (and equal to that which would be demanded) were the flow temp to be at the value set by the wc curve, and the heat pump operating continuously without regard to minimum output.

Put simply, the heat pump still follows  (when cycling) the energy demand that the wc curve implies, even though it does so by time slicing.  When stated that way it would be disappointing if it did anything else!

Just first thoughts, feel free to critique!

Posted by: @jamespa

↑

which is uncertain because we don't know the emitter temperature due to the fact that when the hp is off the flow temperature will drop back

Actually, we do know the LWT and RWT when the heat pump is off, see my charts, and so can estimate the radiator temp, say an average of the LWT and RWT.