Other Setting Implementation #69
Replies: 3 comments 2 replies
-
Seems that makes sense as the implantation order. I am not sure what needs to be passed at this moment, nor am I certain about how to handle all 4 types. My hunch is to handle them in the same methods but 4 times each, but I am thinking I'll try one first. |
Beta Was this translation helpful? Give feedback.
-
What you have discovered could be major breakthrough. I'm not sure yet what we can do with it, but I will think about it. I made two changes in my last refactoring. It was initiated by the desire to circumvent the difficulty of uncertainty regarding the air conditioner's ACK (following a request to change operating parameters or an update of the outdoor temperature). So, I wanted to make the mechanism more optimistic. This means that:
|
Beta Was this translation helpful? Give feedback.
-
From Kumo FC 42 01 30 10 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5D FC ok I've never tested this (despite I have kept the code in my component). It would be a big progress to use this. Actually I think the only way to decode these bytes is to have many different types of unit and to compare all the different responses from each model. void CN105Climate::processCommand() {
switch (this->command) {
case 0x61: /* last update was successful */
this->hpPacketDebug(this->storedInputData, this->bytesRead + 1, "Update-ACK");
this->updateSuccess();
break;
case 0x62: /* packet contains data (room °C, settings, timer, status, or functions...)*/
this->getDataFromResponsePacket();
break;
case 0x7a:
ESP_LOGI(TAG, "--> Heatpump did reply: connection success! <--");
// ======================================
// here could come the heatpump functions requests
// But the 10s timeout in the sendFirstConnectionPacket() should probably be increased
// and the comming "this->isHeatpumpConnected_ = true;" should be deferred after the hp response
// ======================================
this->isHeatpumpConnected_ = true; //should be deferred after the hp response as mentionned
// let's say that the last complete cycle was over now
this->loopCycle.lastCompleteCycleMs = CUSTOM_MILLIS;
this->currentSettings.resetSettings(); // each time we connect, we need to reset current setting to force a complete sync with ha component state and receievdSettings
break;
default:
break;
}
} |
Beta Was this translation helpful? Give feedback.
-
So the calling pattern on the serial seems to be that the kumo sends an empty sentence of the type it is interested in. Then the split sends back all the setting in that set. Then when kumo adapter wants to change one setting it sends back all of them in a command.
The same thing happens for the 4 commands.
So I am wondering where a place to start is @echavet ?
Since I don't know what they all mean, I cannot exactly follow the map/byte pattern that comes from the swicago project.
It seems like periodically we need to send the empty sentence, and store it as is until we have a map. Then create a new setting for Thermal Fan (a place to start) and rebuild the sentence. So it will have to be a tad messy until maybe I can figure out what the other bytes mean.
I understood what you were up to @echavet until your last major refactor :P so I will have to spend time reabsorbing your pattern! But I think I can just insert this in your "loop" that is checking temp and others...
As some point I am going to give it a go as a POC then once we have a pattern we can iteratively add settings. But there are so many I cannot figure out if there are 4 with 15 each = 60! WTHeck could they be?
Beta Was this translation helpful? Give feedback.
All reactions