[curlymo]

It's great to see three fan remotes at the same time. The pattern between the three is beautifull

It would be great though to also see another light remote. @Niek, do you have time to implement the fan remote into a fan protocol?

[marco-f]

Can you maybe get another remote. The codes you posted are a lot clearer then the ones posted before. But, before i adapt the protocol, i want additional confirmation.

Maybe I have found another remote, but I get different informations. My father in law says they have the same set, my mother in law says they have another one. So i have to look for myself when we are there on our next visit.

If they have the same set I just have two options - make all my loggings there or leave my set there and take their set home with me.

Thats why I have two questions:

1. Do you need addtional informations from my set? If I leave my set there I will be unable to get additional informations from my set until my next visit there.

2. If I make loggings with their set within my visit, what should I log? The same as I did with my set? Signals from all Buttons with rawlen 50?

Regards,
Marco

[curlymo]

I just want the same output as before. That helps me validate the previous output generated from other remotes.

[Niek]

@Niek, do you have time to implement the fan remote into a fan protocol?

Did you really intend to ask me to implement such a protocol?

Althought I am not a 433.92 protocol expert, I probably could manage to analyze the pulsetrains and implement such a protocol, but not for several weeks to come unfortunately.

[curlymo]

Yes, just wondering

[Niek]

@curlymo

Looking at the information provided by @marco-f, I came to the conclusion that creating a protocol for this device can be done, but will be  too much work for me now.

In fact this is a composite device needing:

• a switch for lamp on/off
  
• a switch for fan on/off and a switch for fan left/right, or a new type of switch combining both of them.
  
• a slider to control  the fan speed.
  

In theory the lamp switch could be separated from the fan controls so one would have two different devices in the GUI.

Anyway, this will require a new device type with corresponding GUI representation. I am not familiar with fans at all, so I don't know if such a protocol would not be too specific for just one brand.

[curlymo]

The switch would be a good start.

[Niek]

I had another look at the characteristics of the fan protocol. 
Lamp and fan are each being switched with a single pushbutton, so no separate buttons for on and off.
 
If we would make a protocol based on normal (stateful) switches, ofc we can let the protocol send the same codes for on and off, and toggle between states when the remote is being used, but that would have a big disadvantage. If the state of the device in pilight gets out of sync with the physical device, there would be no way to correct that from pilight like we can do with a normal switch (by switching back and forth once). 
Only if we would leave out receiving capability from the protocol, the remote could be used to bring the state of the physical device back in sync with pilight.

So imho using normal switches wouldn't be a good idea. The fan protocol will require stateless switches  ("pushbuttons") instead. Forgive me if I am wrong, but as far as I know there is no such hardware type within pilight yet. I am sorry, but developing such a thing would be beyond my capabilities now, apart from the lack of time

[curlymo]

When looking at the pulse streams it does seem to support separate on and off. Check the AX and AY columns in the attached ods.

[Niek]

Yes, but the fan is not a Clarus device! 
If I did correctly understand what @marco-f wrote, pilight recognizes the pulsetrains from the remote as Clarus, but the fan does not respond when that protocol is being used. My conclusion is that the pulsetrain of the fan remote has the same general "format" as Clarus (like raw length and pulse length) -so passes the validation for that protocol-,   but has a different encoding.