Egyras / HeishaMon

Panasonic Aquarea air-water H, J, K and L series protocol decrypt
217 stars 113 forks source link

Renaming heat curve fieldnames to reduce confusion... #492

Open stumbaumr opened 3 weeks ago

stumbaumr commented 3 weeks ago

Writing and debugging rules I get again and again confused... "Is high the target or outdoor temperature again?"

Maybe this happens also to other people here - use that thumbs up button down below!

Proposal: Rename fields to

TOP29   Z1_Heat_Curve_Left_Target_Temp      40  °C
TOP30   Z1_Heat_Curve_Right_Target_Temp     32  °C
TOP31   Z1_Heat_Curve_Right_Outside_Temp    12  °C
TOP32   Z1_Heat_Curve_Left_Outside_Temp     -10 °C

Maybe that helps - if you don't like that idea use the thumbs down button below...

edterbak commented 2 weeks ago

Hi

This is the default: TOP29 | Z1_Heat_Curve_Target_High_Temp = Water temperature, high value TOP30 | Z1_Heat_Curve_Target_Low_Temp = Water temperature, low value TOP31 | Z1_Heat_Curve_Outside_High_Temp = Outside temperature, high value TOP32 | Z1_Heat_Curve_Outside_Low_Temp = Outside temperature, low value

image

If you think about what happens, it kind of sounds logical as it is:

I find current situation and your suggestion are both equally fuzzy / difficult. They both require a good 2nd look. I think in this case it is maybe better to increase the documentation.

Im not in favor of renaming mqtt topics for only estetic purpose. :) This can give a lot of extra work for others. (I am a victim in this case) But, If it truely has significant benefits it might be worth the effort IMHO. But.. in this case I do not see it that obviously.

Just my thoughts about it :)

geduxas commented 2 weeks ago

I personally prefer to use terms or shorts as used in service manual, Outside High/Water Low, Outside Low/Water Hi (O_Hi/W_Lo, O_Lo/W_Hi)