@istvan.szirtes: thank you very much for your effort, i appreciate it a lot!
I use the stick to control an awning (Weinor Opal Design) at my house.
Is it possible to invert the states when the device class is an awning? HA reports the state as OPEN if the awning is retracted and CLOSED if extended.
regards,
Michael
Hi Michael,
Thanks for your usage of my lib.
Yes I can do your request. However, before I do it, please tell me that does the open and close command work perfectly? Does the open command open, extend the awning and the close command close, retract that? Is just the state wrong? Is there any other functionality next to the open and close what we want to handle?
Thanks,
István
Hi Igor, Andy,
Please give me some time to analyze your problem, and create a new version of the lib with some debug logs and it would be good that you test it and create logs with it to me. One or two days I will come back with it.
Until then, I can collect some info to you:
Thanks for the linked Eva-Kit tool. However, I know it and I used that for the design of my implementation and for the test. The problem with this tool is you can control/use/test just one channel in one time. You can’t control more channels with one command like a MultiTel2 remote control. Unfortunately, the firmware of the Elero USB Stick is bugy. This is why I have to control every channel separately with different commands. This is why I have to send as many command as covers are controlled. This is why the LED is blinking rapidly. This is normal. A command is sent and the response is processed. You can’t verify the rapid blinking with your eyes. But, if you create a slow‑motion video with iPhone you can see every orange-green blinking.
Please find this note from the Elero user manual:
Status indicator (LED) on the Centero Transmitter Stick:
orange flashing: Channel (sender) not taught-in into any receiver
orange flashing rapidly: Channel (sender) in bidirectional teaching mode Operation of receivers already taught-in not possible (except for STOP button to cancel teaching mode). In group teach-in mode every 2 seconds (even without button pressing)
orange then green: Receiver has received the signal
orange then red flashing: One of the receivers did not receive the signal
The “* orange then green: Receiver has received the signal” is important. Every blink what you see is this. I hope 
for me is yes. My system works perfectly with individual channels and groups too. The automation works what I want. I hope for you too.
About the states.
Please test your system with this tool and HA too and send the result to me. What I want to verify is the hex responses of the Eva-Kit tool and your HA.
I think we can refine the states based on your needs and logs after a sort discussion about how would be the state good
Thanks,
István
Hi,
I made changes on my Elero lib. Please @mbr, @Igor_Jurisic, @andy-online try it and share your experiences and your logs with me for analyze your states.
thanks,
István
Thanks a ton @istvan.szirtes that you are back and spending so much effort into this component!
Also thank you for your explanations!
I’ve updated my installation to your latest version and can see, that the status is still not correct.
I want to give you an example.
For channel 11, when plugging the stick into the WIndows machine and using the Elero Eval Tool, I see status “Stopp in oberer Endlage” = “opened”.
The tool says:
Sent: 0xAA 0x04 0x4E 0x04 0x00 0x00
Recieved: 0xAA 0x05 0x4D 0x04 0x00 0x01 0xFF
But then in HA I can see “unknown” as status for the same channel:
I do not know how to find more details about this “unknown” state in HA - is there any way to read out the hex code which had been received? Or is there any log file which would help you?
Many many thanks again - just let me know how I could support you in improving this component!
By the way: Controlling the shutters seems to work fine - it is just displaying the status which does not work for all shutter correctly.
Hi @andy-online,
please send your “home-assistant.log” file to me via mail: [email protected] which is created with the latest version of the elero lib.
You can find the sent and received hex data in the log like this:
2018-11-23 16:54:41 DEBUG (SyncWorker_7) [custom_components.elero] Elero transmitter: ‘1’ ch: ‘{3}’ serial command: ‘b’\xaa\x04N\x00\x04\x00’’
2018-11-23 16:54:41 DEBUG (SyncWorker_7) [custom_components.elero] Elero transmitter: ‘1’ ch: ‘{3}’ serial response: ‘b’\xaa\x05M\x00\x04\x02\xfe’’
Thanks,
István
Here is an example from my log file:
2018-11-24 08:16:52 DEBUG (SyncWorker_12) [custom_components.elero] Elero transmitter: ‘1’ ch: ‘{11}’ serial command: ‘b’\xaa\x04N\x04\x00\x00’’
2018-11-24 08:16:52 DEBUG (SyncWorker_12) [custom_components.elero] Elero transmitter: ‘1’ ch: ‘{11}’ serial response: ‘b’\xaa\x05M\x04\x00\x01\xff’’
2018-11-24 08:16:52 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=cover.kuechefenster, old_state=None, new_state=<state cover.kuechefenster=unknown; friendly_name=KuecheFenster, supported_features=11, device_class=window @ 2018-11-24T08:16:52.130038+01:00>>
I’ll send you the complete log file via e-mail…
One more small finding, which is somehow related to the wrong status:
I’ve created several cover groups, but as far as I can see, when the group contains a shutter with status “undefined”, the complete group gets the status “open” (and not “undefined”). Properly that leads to that the “open command” is grayed out and cannot be clicked - just the “close command” and “stop command” are available then.
So I cannot open the complete group, but just could close it. 
If it is possible and does cause too much effort, I feel it would be better that the complete groups also gets the status “undefined” if the shutters in the groups have different statuses and/or one shutter has status “undefined”. And in that case, it should be possible to send the “open” and “close” command to the group.
Hi @andy-online,
You can find the decrypted commands by me:
2018-11-24 08:16:52 DEBUG (SyncWorker_12) [custom_components.elero] Elero transmitter: ‘1’ ch: ‘{11}’ serial command: ‘b’\xaa\x04N\x04\x00\x00’’
This command is the Easy Info during the normal update process of the HA. Everything is correct with it.
header: \xaa
length: \x04
command: N -> 4e
chH (9-15): \x04
chL (1-8): \x00
cs: \x00
2018-11-24 08:16:52 DEBUG (SyncWorker_12) [custom_components.elero] Elero transmitter: ‘1’ ch: ‘{11}’ serial response: ‘b’\xaa\x05M\x04\x00\x01\xff’’
This command is the Easy Act (the answer on Easy Send or Easy Info) sent by your cover to the HA. The info data ‘\x01’ means that ‘Top possition stop’.
header: \xaa
length: \x05
command: M -> 4d
ch H: \x04
ch L: \x00
info data: \x01
cs: \xff
2018-11-24 08:16:52 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=cover.kuechefenster, old_state=None, new_state=<state cover.kuechefenster=unknown; friendly_name=KuecheFenster, supported_features=11, device_class=window @ 2018-11-24T08:16:52.130038+01:00>>
I could not find any reasons or errors to your unknown state. However, I put some more debug logs into the code based. Please update your elero lib and create another log for me and sent it, thanks.
Is your HA updated?
The updated lib is on my Github
All my covers work well. All statuses are good. Very interesting thing what you reported…
Hi Istvan,
I just checked the states of my shutters. My shutters’ states are also unknown.
Many thanks @istvan.szirtes,
I’ve sent you the new log file via e-mail after having updated the two python files and rebootet HA.
Yes, I hope my HA is updated, it is showing V0.82.1 .
Is it that what you are searching for?:
2018-11-25 14:36:43 DEBUG (SyncWorker_17) [custom_components.elero] Elero transmitter: '1' ch: '{11}' serial command: 'b'\xaa\x04N\x04\x00\x00''
2018-11-25 14:36:43 DEBUG (SyncWorker_17) [custom_components.elero] Elero transmitter: '1' ch: '{11}' serial response: 'b'\xaa\x05M\x04\x00\x01\xff''
2018-11-25 14:36:43 WARNING (SyncWorker_17) [custom_components.elero] Elero the channels are not matched! HA ch: '{11}' response ch: '{3}'Hi All,
@andy-online No, no. I never give up! I work for your satisfaction…and…I have a good news for you You found a bug in my code. Yep! This is why I involved you into the usage of my lib as a beta tester. Thanks!
I have 7 covers and I use the channels from 1 to 7 only and my test coverage was weak.
Unfortunately, I made a mistake at the channels handling. The upper channel bits handling was wrong and this causes that the channels from 9 to 15 never got the correct state just the unknown state because the channel number never matched with the set channel number.
I have corrected this mistake, so you can test it. Please share your result as soon as you can.
@andy-online, @dierk86, @mbr, @Igor_Jurisic Please update your custom component from my Github:
Thank you for your patience.
István
No no no - not I did find a bug in your code - I just sent you some log files - you found it and fixed it!
After your description it also is now clear for me, that the shutters channels 9 to 13 reported wrong status. I guessed it would be caused because of the shutters are too far away and cannot be reached or did not response fast enough. But as I do a numbering of the shutters in clockwise rotation, it was just bad luck, that the shutters most far away are the ones having the high channel ID.
Sorry, that I did not see that it only affected the high channel IDs, otherwise I would have given you that hint and searching this issue would have been easier.
I did a first short test and the status seems to be correct now!
Great - many thanks! 
I will do some more tests in the next days, also playing around with the groups and tilt / ventilation positions and give you more feedback then.
But at the moment it is already great!
Wohoo!! It works 
No more “unknown” status! Awesome job Istvan, you are a life saver
We finally have a fully functional shutters.
Many many thanks again to @istvan.szirtes for spending so much time into this add-on!
I first wanted to confirm that the status reporting of the shutters now is absolutely fine.
I hope you don’t mind, but I’ve found some other issues.
a) Several warnings in the log file like:
2018-11-27 21:03:15 WARNING (SyncWorker_15) [custom_components.elero] Elero the channels are not matched! HA ch: '{3}' response ch: 'set()'
2018-11-27 21:05:03 WARNING (SyncWorker_13) [custom_components.elero] Elero the channels are not matched! HA ch: '{3}' response ch: 'set()'
2018-11-27 21:05:12 WARNING (SyncWorker_15) [custom_components.elero] Elero the channels are not matched! HA ch: '{10}' response ch: 'set()'
2018-11-27 21:05:21 WARNING (SyncWorker_10) [custom_components.elero] Elero the channels are not matched! HA ch: '{10}' response ch: 'set()'
2018-11-27 21:08:21 WARNING (SyncWorker_6) [custom_components.elero] Elero the channels are not matched! HA ch: '{10}' response ch: 'set()'
2018-11-27 21:27:30 WARNING (SyncWorker_17) [custom_components.elero] Elero the channels are not matched! HA ch: '{10}' response ch: 'set()'
or
2018-11-28 07:28:43 WARNING (SyncWorker_12) [custom_components.elero] Elero the channels are not matched! HA ch: '{1}' response ch: '{13}'
2018-11-28 07:28:44 WARNING (SyncWorker_17) [custom_components.elero] Elero the channels are not matched! HA ch: '{13}' response ch: '{4}'
I am not sure if they are causing any problems, …
b) The commands I can send to groups are somehow incomplete when the shutters in that group have a different state.
Here is an example as drawing:
But I am not sure if this can be solved in the Elero component, or if this is a restriction of HA in general…
c) When I send commands to a group of shutter, often only one or two shutters are moved.
Example: I have a group for all 6 shutters:
platform: group
name: "WohnEssZimmer"
entities:
- cover.WohnzimmerTuer
- cover.WohnzimmerRechts
- cover.WohnzimmerLinks
- cover.KuecheFenster
- cover.KuecheTuer
- cover.Abstellkammer
wohnzimmertuer: channel: 8
wohnzimmerrechts: channel: 9
wohnzimmerlinks: channel: 10
kuechefenster: channel: 11
kuechetuer: channel: 12
abstellkammer: channel: 13
All shutters are opened.
Now I click on “closed” for the complete group.
But then only the shutters 8, 9 and 10 get closed, the rest is unchanged.
I feel it is randomly which of the shutters get closed in that case, it also happened that e.g. only one of the six shutters get closed.
I reproduced this issue now (as described above) and created a log file which I’ll send to you via e-mail, @istvan.szirtes.
Hi Andy,
Sorry for my late answer. Please find my findings below.
a) warnings in the log file:
It does not cause any problems just state update delay. The next HA update process will update the channel states.
I would like to develop a class to handle this anomaly. Another solution can be the correct asyncio handling. The HA supports it and I want to refactor my lib into that.
b) state of the group controls:
The state of a group is in the hand of the HA. I can change or influence that.
However, I am going to analyze and read that HA code of the group handling and find out something…
Here is my groups (sorry the Hungarian naming):
c) movement of the items in a group:
I experienced something similar as you do in the previous HA versions. But, I do not experience it in the last two versions. This is a recurring problem of you but not me. It is very interesting that all of my groups work correctly. All covers controlled correctly by its group or groups. All my automations work correctly too. Please create a log file about this situation and we can verify the send commands.
Do you have any news about the tilt/ventilation positions?
Thank you for your patience.
Best Regards,
István
Many thanks for your answer, @istvan.szirtes.
Yes, what I can see in your screenshot is what does not work im my HA. 
But I do not have any idea about the reason for that.
It’s a pity that I cannot send commands to a group if the shutters in that group have a different state (why the arrows are greyed out then). 
I’ve now also updated to HA 0.83.2 but still it is not working that all shutters are moved when I send the command to a group.
I already sent you a log file from this operation a few days back, I sent it now again.
I’ll come back to tilt / ventilation mode later, first I want to think about it again, if I did any mistake there.
I want to come back to the tilt / ventilation modes etc.
I am a bit confused from the documentation. Here are two screenshots from your readme.md and one from the Eval tool:
So how to describe it best?
In the Elero tool, I can see the commands up, down, stop, intermediate position (in German “Zwischenposition”) and ventilation position (in German “Lüftungsposition”).
But in your readme.md, as supported features I can find set_position and set_tilt_position instead.
Does set_position mean intermediate position?
And set_tilt_position mean ventilation?
Additionally it is not clear to me what the commands “tilt open/close/stop” could do… I think the shutters and the transmitter stick does not support that?
Also the Elero Stick documentation only knows 5 commands:
Or is my confusion more caused because the supported features and their names come from HA and you had to chose / select them according to the HA requirements?
I now played a little bit more around with the intermediate position and ventilation position, but I did not got that working up to now.
I defined it like this:
rolloarbeitszimmer:
transmitter_id: 1
name: Arbeitszimmer
channel: 1
device_class: roller shutter
supported_features:
- up
- down
- stop
- set_position
- set_tilt_position
This is how it looks like:
So directly I can only click on “open”, “stop” and “close”.
I would expect that there is also something to click on “move to intermediate position” and “move to ventilation position”. Both commands should work without giving an argument to this method. I mean, the Elero shutters only can execute e.g. “move to ventilation position”, but they do not support something like “move 30%”. The both positions “intermediate” and “ventilation” can be programmed separately and are stored in the shutter itself.
Also when clicking/moving the sliders HA “Position” or “Kippstellung” (= tilt?) just nothing happens… The shutters are not moving.