So I inserted the Elero transmitter stick into my Windows machine and executed the tool from Elero.
When I then click on “info” for every channel, then I can see the following:
(Sorry, that everything is on Germany on my machine)
So as I can see - for every channel the correct “open” status is returned (“Stopp in oberer Endlage” = “Stop in upper end position”; meaning open), nothing with “undefined” or similar.
From my point of view this shows that the paring of the shutters to the transmitter stick is fine, the stick is working fine and also all shutters are working properly.
It is just that Home Assistent does not work correctly with the stick up to now…
Yes, let’s hope that @istvan.szirtes comes back and has time to investigate this.
If anybody needs log files, please just ping me and let me know which log file is needed / how extended logging can be enabled.
When I look at the LED on the transmitter stick, I think the blinking is a quite bit “strange”. Normally, when a command is sent (e.g. to get the status or to move a shutter), the LED does indicate this with an orange color. When the answer is received, it should show that in green color. I think both colors show be visible for around 1 second.
But when I watch the LED of the stick while it is used by HA, it is more flickering / flashing, my feeling is, it is much too fast (and the system is not waiting enough time for the response).
Also in comparison when I’ve used the same transmitter stick with FHEM, the blinking was much slower…
So my feeling is, that the stick should be used in a slower way and HA should wait a longer period for an answer, so not to miss the answers from the “slower” shutters. But playing around with the timing parameters also does not help on my system.
No it isn’t…actually it’s very close (few meters).
But I do remember that binding that shutter took a few tries originally (with stick and outdoor sensero wind sensor).
That’s why I suspected that full-duplex (or whatever it’s called) doesn’t work properly.
@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.
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?
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
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 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
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.
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:
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.
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
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
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…
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}'
@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.
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!
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:
The covers “SchlafzimmerRechts”, “SchlafzimerMitte” und “SchlafzimmerLinks” are in the group “Schlafzimmer”. For the group “Schlafzimmer” I cannot click on the “open” command, when two shutters of that group are closed and the thrid I stopped in a manual position or is already opened.
I would expect, that I can click on “open” for the complete group even if one shutter is already opened.
But I am not sure if this can be solved in the Elero component, or if this is a restriction of HA in general…
