Initializing an instance of the Daikin152Protocol

[DozoG]

I have built an IR-sender to control my Daikin AC , that works just fine.
It receives commands for temperature, fanspeed etc from HomeAssistant over TCP.

In summer my AC is on day and night, but in the daytime i set the fanspeed low and the temperature to about 26C
I have an idea to create two instances of Daiking152Protocol (which is a struct inside a union)
For example:
Daikin152Protocol Day; Daikin152Protocol Night;
Then a button in homeAssistant or an automation based on the time, sends a request to copy Night.raw into _.raw (the Daiking152Protocol that is a member of the class IRDaikin152)
There conveniently already is a function

void setRaw (const uint8_t new_code[])

My question/problem is... how do I initialize my 'Night' -instance (since it has bitfield labels)

Daikin152Protocol Night={ .Mode = kDaikinCool , } ; // dont forget to get the checksum

compiles (in PlatformIO) , but it isnt a full configuration for my settings

Daikin152Protocol Night={ .Power = 1 , .Mode = kDaikinCool , } ;

Does not compile, it gives an error: error: too many initializers for 'Daikin152Protocol'
I have googled around for a bit. Its possible My compiler doesnt allow it or something. On the other hand it may just be tha I am not using the right syntax.

Can I initialize an instance like this?
Or is there a function to set an entire content of a Protocol at runtime?
(It looks like the only funciton available is setRaw( ) , but if I declare an array, I can't use the bitfield labels (.power , .Mode etc) to initialize it.

[NiKiZe]

As in the FAQ we can't help you with programming, but if you only have 2 states, maybe you should just use them thru the raw state, you can even store them and transfer them thru that.

[NiKiZe]

There already is functions to grab and restore the full state (with a few exceptions for some protocols) of the state, as I explained.

Use getRaw() to get a representation of that state.
Use setRaw(x) to restore that state.

[DozoG]

Yes, thats what I am using, but those will only set and get from the fixed instance of Daikin152Protocol in the class.
So if i want to store a separate configuration, I have to set it there first, then copy it out to a separate array.
Manually initializing a buffer is error prone, because (for example) fanSpeed and Vswing are in the same byte.

I don't mind. It can be worked around.

But please take a look at the byte where Temperature is set. I think the library contains an error there.

[NiKiZe]

Except for toggles there generally shouldn't be any different settings, other then thru the raw buffer, that is also how incomming it messages are parsed.
There might be new remotes, or bugs, but if so we should get updated test cases for those.

Create a new instance of the class, setRaw and you should have the full state.

[DozoG]

What would you need to see (from me or otherwise) before you consider a bug or an update?
What is a test-case?

I have this box you can see in the picture, its relatively easy for me to generate some report in an excel sheet, as long as I know what you require.

[DozoG]

Some of mine and your replies have disapeared. And my pics are not shown anymore.
I am ok. Thanks for your replies.

[DozoG]

Oh btw.
I am using a new Daikin airconditioner that comes with remote controller ARC480A80.
There a are a few small differences between that remote and the remote as implemented in ir_Daikin.h

A relatively big difference is how and where _.Temp is stored.
in the file: ir_Daikin.h , the Daikin152Protocol looks like :

struct {
    // Byte 0-4
    uint8_t pad0[5];
    // Byte 5
    uint8_t Power :1;
    uint8_t       :3;
    uint8_t Mode  :3;
    uint8_t       :1;
    // Byte 6
    uint8_t       :1;
    uint8_t Temp  :7;
    // Byte 7
    uint8_t :8;
    // Byte 8
    uint8_t SwingV  :4; 
    uint8_t Fan     :4;
    // Byte 9-12
    uint8_t pad1[4];

.. where the Set temperature is stored in the 7 most significant bits (which are sent last because LSBfirst)
However, in my physical remote, the temperature is stored as 2T in the 7 least significant bits (sent first)
The temperature is stored as 2T, because that is the easy/chosen way to convert the resolution of 0.5 degrees into a simple integer.
This is also how SetTemp (const float temp ) is implemented in the IRDaikinESP class
Mathematically this works for remotes using a 1.0C resolution, because a single bit shift is (also) a multiplication or division by 2

So I borrowed and modfied this SetTemp function for the IRDaikin152 class. And also modified the Protocol

struct {
    // Byte 0-4
    uint8_t pad0[5];   
    // Byte 5
    uint8_t Power :1;     
    uint8_t       :3;     
    uint8_t Mode  :3;  
    uint8_t     :1;
    // Byte 6
    uint8_t Temp  :7;      // now here
    uint8_t       :1;           // and this not used             
    // Byte 7
    uint8_t         :8;
    // Byte 8
    uint8_t SwingV  :4; 
    uint8_t Fan     :4;    
    // Byte 9            
    uint8_t SwingH  :4;  // Added SwingH in byte 9
    uint8_t         :4;
    // Byte 10-12
    uint8_t pad1[3];     // padding now only 3 bytes 

Then, related to Temp setting:

• in the V286 library:
  kDaikin152DryTemp = kDaikingMinCoolTemp // is 18C

• in my remote:
  the Temperature in Dry Mode is fixed to 32.0C ( not shown in the display in this mode)

• in the V286 library
  kDaikin152FanTemp = 0x60

• in my remote:
  the Temperature in Fan Mode is fixed to 25.0C ( not shown in the display in this mode)

I do not know what my AC will do with 0x60 in FanMode, but its definitely not what my remote consistently sets for FanMode
(even considering the .Temp bits stored differently in the byte.)
Its possible the intention at some point was to set the temperature in FanMode at 30C, which mutltiplied by 2 is 60 , but then incorrectly coded as 0x60 which is decimal 96.

[DozoG]