Hello Steffen, do you see telegram in the logs coming in?
Hello Philipp,
yes, I do. The address of the sensor I just triggered repetitively is feda656d as shown below. It recognises the different positions in the logger, but the state is always “closed” when I check the device state.
2024-02-17 22:11:18.573 DEBUG (SyncWorker_35) [eltako] decoded : {"_movement": 240, "_handle_position": 0}
2024-02-17 22:11:18.794 DEBUG (Thread-2) [eltako] [Gateway] [Id: 1] Received message: <RPSMessage from fe da 65 6d, db0 = e0, status = 0x20 (T2, U, 0 repetitions)>
2024-02-17 22:11:18.797 DEBUG (SyncWorker_41) [eltako] decoded : {"_movement": 224, "_handle_position": 1}
2024-02-17 22:11:18.969 DEBUG (Thread-2) [eltako] [Gateway] [Id: 1] Received message: <RPSMessage from fe da 65 6d, db0 = f0, status = 0x20 (T2, U, 0 repetitions)>
2024-02-17 22:11:18.974 DEBUG (SyncWorker_6) [eltako] decoded : {"_movement": 240, "_handle_position": 0}
Hello Steffen,
I see there is a bug. Can you try to put it under sensors instead of binary_sensors? There it should even provide more info.
I can fix the binary_sensor support.
1 Like
Hello Philipp,
when I put it under sensors I get a third entity called “windowhandle”. This one actually indicates the state correctly, but of course it is not the correct device class.
Please find the log below:
2024-02-18 20:23:57.921 DEBUG (Thread-3) [eltako] [Gateway] [Id: 1] Received message: <RPSMessage from fe da 65 6d, db0 = f0, status = 0x20 (T2, U, 0 repetitions)>
2024-02-18 20:23:57.924 DEBUG (SyncWorker_56) [eltako] decoded : {"_movement": 240, "_handle_position": 0}
2024-02-18 20:23:58.321 DEBUG (Thread-3) [eltako] [Gateway] [Id: 1] Received message: <RPSMessage from fe da 65 6d, db0 = e0, status = 0x20 (T2, U, 0 repetitions)>
2024-02-18 20:23:58.325 DEBUG (SyncWorker_8) [eltako] decoded : {"_movement": 224, "_handle_position": 1}
Hello Steffen,
the binary sensor is fixed on main now.
for the sensor can you just edit the device class manually to window in HA? Not sure if this is possible.
1 Like
Hello Philipp,
thanks a lot for fixing the binary sensor. I will just wait for the next update to come out.
Regarding the device class, I already defined it to door or window, but those entities will always display closed. Only the entity window handle will show the correct state
Hello,
Could it be that all entities are new again since the last update?
Is there a way to get around this?
yes, in the beginning I was not aware of the official schema how ids should be generated. In order to clean up the code and make everything compatible I had to change it slightly. (‘-’ is replaced through ‘_’)
There was a warning in HA that it’s quite likely to run in out-of-support for those ids.
Sorry for that. In my tests it was always ok to remove the whole gateway/hub and add it again and everything was clean and worked again.
OK. Thanks.
Then I’ll try to see if it’s enough to re-enter the gateway
OK. Thank you very much, it worked
1 Like
Hello, it seems as if an bug has crept in when the roller shutter is in the intermediate position, the status is closes instead of opened with the corresponding percentage value.
I think the problem existed once before
Hello @alq.cev,
I’ve tried out to convert the esp2 messages to esp3 messages and send them via Python EnOcean.
I can send out the messages. I do see another gateway is receiving it. BS1 messages like regular switches work and the actuators do react on it.
So far so good. Now I wanted to test if I can send the command to switch on lights from HA. This is a _4BSMessage message like you described above. I can generate the message and send it but my FSR14 is not reacting on it.
Function to convert from esp2 to esp3:
Sent while debugging in VS Code:
Received in HA:
Unfortunately, FSR14 does not react on it. Maybe it has something to do with the outgoing-flag which is not used.
If I simulate a switch it works:
(Here only channel 1 is relevant.)
How is it behaving on your end?
Any ideas what to do?
Hello @netzgauner,
unfortunately, I have right now no real covers/shutters to test with. If the referenced cover.py is working for you I can take it over.
Hi @philipp14,
It had actually worked. Only since the last update something must have changed. Since then, this problem has been.
The referenced cover.py doesn´t work anymore. I think there were to many changes since the time.
Did you try out main branch? There I changed it back to the version which you mentioned works.
Hi @philipp14 I just tried the cover.py from the main branch, but it is still showing opening/closing even though it stopped.
Hi,
I’ve just updated myself and have the same problem with the covers. It looks to me that there is no more feedback when the cover is in open or closed state.
One cover I even can’t control anymore.
It gives me the following message: This entity is no longer being provided by the eltako integration. If the entity is no longer in use, delete it in settings.
One other weird thing is that every light does not have the correct little slider. When I switch one on and off the little slider switch apears again. Like in the picture below
I removed the hub and reinstalled it but it changes nothin.
For me the entities all showed the not present anymore error so I completely removed the integration and installed it again. This fixed the not present error. The strange switches for the lights disappeared after the first time I used them and then the correct switch was displayed again.
Small update:
I just restarted HA and all covers I had shut with HA became unavailable. After manual (pressing the button in home) opening them back up they became available in HA again and the position sttus after closing is correct again
Did you used the cover.py from the latest release or the main branch?