Update HeatPumpType.md #142
Conversation
Added: WH-ADC0309J3E5 WH-UD07JE5 KIT-ADC07JE5 62 D2 0B 45 54 42 D2 0B 72 66
WH-ADC0309J3E5 WH-UD07JE5 KIT-ADC07JE5 62 D2 0B 45 54 42 D2 0B 72 66
|
Can you confirm your model number? |
|
In several commerciall annocements you can find ,that KIT-ADC07JE5 is WH-ADC0309J3E5 and WH-UD07JE5 ... So probably that are correct data. Since internal is 0309 ( so it is universal from 3kW to 9kW ) ,only difference to vary them is outdoor unit ( even in practice is the same).... |
|
Yes I know this but I am trying, once again, to decode the byte values and "42 D2 0B 72 66" should be the outdoor unit. Which is this case already points to WH-UD09JE5 in model type 8 and with this suggested PR this would be pointing to WH-UD07JE5 also, which is unexpected compared to the other values in the table. |
|
This is the heatpump data on which I based my edit: |
|
Don't remember... It could be even someone from Slack , who give this datas... This one was first J type , probably was a good check of it.... |
|
@IgorYbema ,if you have some ideas , we could try to send them via TAW1 to Service Cloud, and see ,how Panasonic will interprate it ( what model it will give). |
|
Ah yes that is a good method to test. First of all maybe just try to test all known heatpump types we already have? To make sure we didn't make any mistake. |
|
Ok.... But looks like update on SerwiceCloud this particular data takes long time , new model is refreshing app after 15min... So now i'm on pos3 of the list ( from 49 :) ) |
|
Looks like this update of HP takes long time , even 3h....
|
|
So generally , b[131] and b[136] don't influence/change thy type of inner and/or outher unit , i can place anything there... Changing the b[132] to 0x45 gives Inner unit as WH-ADC0309J3E5 , and outher remains same WH-UD09JE5-1 ....
|
|
Panasonic in LCD, also taw a2w app will split it to 4 segments, One segment is for IDU, and second for ODU, i almost shure that last digit in longer value represents some sort of version/revision(A/B/C/D) of model.. also because of same structure are in monoblocks, i think it somehow tied to main board version/configuration.. |
|
Yes when I remove byte 131 and 136 I already can remove some heatpump types differences (which are marked new version). So that is a good thing.
But this ones are also weird. For example the 12 D0 06 11 which exists twice with different model number. And the model WH-UD12HE5 has two different bytes (06 vs 10 at b[137]) @MiG-41 can you try this ODU bytes in your test to see what happens?
|
|
Ok , will try.. Now such thing: Gives Outer unit unknonwn: So tried to put to my HP T-CAP 12kW 3phase put outher unit T-CAP 9kW 1phase... EDIT: No , after some time finally it apears: |
|
I think first two bytes will mean some configuration, and rest 3 will remain to software or pcb with some sort of revision.. |
|
|
|
|
|
|
|
Still unknown , so will make another mix... |
|
|
|
So pos 25 is wrong, It can't be UD since it is T-CAP ,it have to be UX... EDIT: Yes , pos.25 on the list has wrong ODU , should be described as WH-UX12HE5 |
|
Also funny , when it can be two Monoblock at the same time :) |
|
So indeed they have some kind code>model mapping table.. and for monoblocks i think they have same models for odu and idu.. so this explains why it's showing different model's.. if we could somehow access that table :D |
|
I'll update nr 25 on the list. Thanks for finding that. |
|
Looks like it can be any kind of mix , like |
|
@MiG-41 @geduxas I'm am testing out v3.9 and want to release it soon. I was hopening to make some smart model test logic in the code but this seems not logical yet. And as it doesn't provide any information I am now thinking of removing the model TOPIC completly (until we finally figure out wat the logic is, if there is any). What are your thoughts about removing the TOPIC? |
|
I don't belive is there any logic , they are just random ( or better next free) with Panasonic takes. Without input from users in my opinion we will not find logic here ( if any). |
|
We could do that but then ending up with a big lists of model types costing a lot of storage memory on the controllers. And it has no function at all. So why bother doing this? |
|
Such option was also some times ago , Heihamon show only pure bytes , in github translation table , and in Heishamon web if possible also online translation from that table. For sure this TOPIC have no function at all. |
|
Best way is to use same logic as panasonic do, and leave model recognition/mapping to endpoints... In some time we could get mapping table and all endpoints could map models.. for now as is it's not logical.. also it's complicated to maintain. And we don't have big database to investigate model/code mapping for now.. As i find out all codes could lead not to model, but in some kind of pcb firmware version and some modification code.. |
|
Ok so if you agree I will remove the translation and only show the 10 bytes. |
|
If possible split bytes to 4 Topic, 10 bytes will not give desired function |
|
I understand but that can be easily done by the end device. And if you keep all 10 bytes in one topic it doesn't need to receive all topics before trying to match to the github list |
|
At least seperate idu and odu.. |
|
First this ( 10 bytes searching in table) , display as much as possible from table . Later have to be considered to ommit byte 131 and 136 , treated as a version ... ( so in github table have to be considered) |
|
Currently I changed it to this. Acceptable? |
Added:
WH-ADC0309J3E5 WH-UD07JE5 KIT-ADC07JE5
62 D2 0B 45 54 42 D2 0B 72 66