Question about protocol MISO

[glsf91]

@absalom-muc I was looking into the protocol difference between mhi-ac-ctrl and the WF-RAC WiFi module (besides the number of bytes in a frame).

Now the behavior of mhi-ac-ctrl regarding the MISO is:

• every 40 frames a new opdata item is requested
• after 20 frames DB14 bit 2 is toggled (doubleframe)

The WF-RAC module is doing this different. Also the AC (mine srk35zs-w) don't answer on a request of opdata command if MISO DB14 bit 2=0, only if bit 2=1.

So my question is about the history of your implementation: Where is the protocol implemented coming from ? Did you see the implemented behavior when the AC was connected with another control device ? So what was the base/history of this MISO implementation.

Of course it is possible another type of MHI AC was used which behavior was different then mine.

[absalom-muc]

I used the protocoll which was applied by RC-E5. I made traces and replicated it. I remember it was a lot of fine tuning necessary and I was happy when it worked. I haven't spend more time to check why it worked only under certain conditions or if it could be improved/simplified.

[glsf91]

Maybe I want to change it a little bit according what I saw with WF-RAC. This also means the opdata will be become faster available. Now it takes 40s to get everything. Do you have any objections on this when I make a pull request with this change?

Of course after testing. And first I have to change my MHI AC simulator (makes it much easier to change things)

edit: what I also see that the response on an opdata request is not always answered right away but several hundreds frames later.

[glsf91]

@absalom-muc And an additional question: In the opdata definition there is also: { 0x00, 0x00}, // dummy Also a comment: "// comment out the data you are not interested, but at least leave the last dummy row"

Is this a valid opdata command because it looks like there is no processing for this opdata? If no:

• what is the reason for this one?
• can this be removed ? (and change the comment in "// comment out the data you are not interested, but at least leave 1 row")

[absalom-muc]

Maybe I want to change it a little bit according what I saw with WF-RAC. This also means the opdata will be become faster available. Now it takes 40s to get everything. Do you have any objections on this when I make a pull request with this change?

Of course after testing. And first I have to change my MHI AC simulator (makes it much easier to change things)

edit: what I also see that the response on an opdata request is not always answered right away but several hundreds frames later.

No objections to the pull request. I have also observed the delay between opdata request and response.

[absalom-muc]

@absalom-muc And an additional question: In the opdata definition there is also: { 0x00, 0x00}, // dummy Also a comment: "// comment out the data you are not interested, but at least leave the last dummy row"

Is this a valid opdata command because it looks like there is no processing for this opdata? If no:

* what is the reason for this one?

* can this be removed ?
  (and change the comment in "// comment out the data you are not interested, but at least leave 1 row")

Yes, you are right, the rule was: at least 1 should be enabled

[glsf91]

@absalom-muc I have it now running with sending 2 frames for every opdata (toggling DB14). This is according WF-RAC. Every 20 frames (10 double frames) the next opdata will be requested. So all opdata will take about 20s and start over again. Changing fan for example will go right away instead of utmost every 40 frames (2s). Between every opdata the default is sended ( MISO_frame[DB6] = 0x80; MISO_frame[DB9] = 0xff;). This is also the case with WF-RAC. So 2 frames with opdata request and 18 frames with this "default".

Opdata 32-38 have a delay in answering. Sometimes the answer comes with the next opdata request (which answer is also delayed), sometimes with the above "default". Maybe I have to reorder them. I have to look further into this.

Only I don't understand the following:

      if (erropdataCnt == 0) {
        MISO_frame[DB6] = pgm_read_word(opdata + opdataNo);
        MISO_frame[DB9] = pgm_read_word(opdata + opdataNo) >> 8;
        opdataNo = (opdataNo + 1) % opdataCnt;
      }
      else { // error operating data available
        MISO_frame[DB6] = 0x80;
        MISO_frame[DB9] = 0xff;
        erropdataCnt--;
      }

It is about the else part. The else part is done when error count is >0. But MISO_frame[DB6] = 0x80 and MISO_frame[DB9] = 0xff is used always in WF-RAC when no opdata is requested. WF-RAC is only requesting kwh, outdoor temp and return-air with an interval. I use this MISO_frame[DB6] = 0x80 and MISO_frame[DB9] = 0xff in between. So when an error occurs in the AC, it is sending also several opdata without requesting this ? Did you test this (and how), because my AC has no error ? Can you tell me a little bit more about this ?

[glsf91]

And an additional thing: When using internal AC temp sensor it can be fluctuating a lot in a short time. Therefore the TROOM_FILTER is there. But this filter will also filter for the external temp sensor. In my case the DS18B20. I don't want to filter for this sensor because it is very stable and I want to see changes of 0.25 degrees. But when restarting the esp it will use the internal sensor for a short period (every few frames), with a burst of changing up and down (0.25) values. So I'm thinking about implementing a max update frequency for example 5s when only the internal sensor is used. Only a new value after 5s will be published. Do you have any objections to this ?

[glsf91]

@absalom-muc Would it be possible for you to look at above 2 comments ? Depending on the answers I can start a pull request.

[absalom-muc]

So when an error occurs in the AC, it is sending also several opdata without requesting this ? Did you test this (and how), because my AC has no error ? Can you tell me a little bit more about this ?

My understanding is: Once you write a random value to ErrOpData the AC sends out some OpData stored during an error condition w/o further specific requests. You have no influence which OpData are send. I just tested it and see the following output Looks not beneficial for me, maybe an AC expert can interpretate the values and conclude the error.

[absalom-muc]

So I'm thinking about implementing a max update frequency for example 5s when only the internal sensor is used. Only a new value after 5s will be published. Do you have any objections to this ?

Is there really a problem?

But when restarting the esp it will use the internal sensor for a short period (every few frames), with a burst of changing up and down (0.25) values

Why do you care this jitter? Is it a cosmetic topic for the start-up phase or something serious? If it is a cosmetic topic only, I would prefer to leave it as it is to limit the SW complexity.

[absalom-muc]

@absalom-muc Would it be possible for you to look at above 2 comments ? Depending on the answers I can start a pull request.

I appreciate your active role. But since my time is currently very limited, I invited you as a collaborator on the repository so that you are not thwart by me.

[glsf91]

Why do you care this jitter? Is it a cosmetic topic for the start-up phase or something serious? If it is a cosmetic topic only, I would prefer to leave it as it is to limit the SW complexity.

Because I put Troom into influxdb. In Grafana I have some graphs. It is disturbing the graphs when this happens because my internal sensor value is a lot higher then my DS18B20. The y-axis will then display a bigger range which make other changes almost invisible for a few hours (because my graph is a few hours). It is about 2 lines of code change :-)

[glsf91]

I appreciate your active role. But since my time is currently very limited, I invited you as a collaborator on the repository so that you are not thwart by me.

Ok, thanks. Maybe I still consult you on some changes. If you see something you don't like, just let me know. Then I will rollback this.

made pull request for this #140