-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Blind controls are not working, but found a way to make them work. #14
Comments
Thanks for digging into this. I have not seen these xml files, I merely started out reverse engineering how to control each device from the web interface. It seems like we for each channeltype can look at channeltype_mainFunctionControlGroup and the control id to map how to control each device, and the corresponding info id on how to read status. I will test it. |
Sorry for the second update, was mixing accounts. Yes mainFunctionControlGroup should work. But you still have to format the request according the outputDeviceFunction call. Sadly I am away the next 2 weeks, but after that I also will try to do some coding. Keep in mind that I am using a Gira server, but the firmware should be the same except some naming differences with the Jung server. |
Hi Jan, I have recently spent quite some time rewriting this as a native integration, and your device will show up (for now as a light), but the blind height is contrallable. Head over to https://github.com/mnordseth/enet-homeassistant to test it. |
Hi Magnus, That is quite interessting, I spend quite some time rewriting the code into an appdaemon home assistant service. So far that is working flawlesly. And blinds show up as blinds, and up-down is working as expected. Open and closed is the other way around with home assistant and blinds. 100 is 100% open and not 100% closed as I would expect it to be. But I must say that I have been replacing some of my enet components with tasmota and zigbee devices. The enet devices are are selling good on the second hand market due to supply shortages and un-availability of stock. Sold like 3 enet switches and bought like 10+ zigbee switches back for the same amount. I will try to commit a branch of my changes in the next days, comparing the code is always usefull, and perhaps certain blocks can be re-used. And it would not hurt to test your code as well. Still the solution isn't great due to the polling, when I turn on my lamps there always is a delay before my touchscreen in the livingroom is updated. For now I will make due. |
I found a way to subscribe for events from the enet server, and has gotten away from the polling. Events from buttons and remotes are instantaneous, while there is a slight delay for events from the actuators. But still a huge improvement from the polling. |
That is a huge improvement indeed, I see you have hard-coded the device types. I made a script that reads the config from the server. But since Enet device updates are quire rare, hard-coded seems to be more easy. I will test and check the code, and see if I can include my code that is registering the correct home assistant type. One thing I was wanting to implement in the future is changing parameters. For example the dimmers have a det default dimming value. If I can automate that, I can lower the default setting at night. |
Yes, the repository is configured with a devcontainer in VS code, that allows you to do live debugging. If you open the repo in VS Code it should automatically launch it in the devcontainer. You run it with "Run task" and can then attach the debugger. |
That would be really neat ... can't wait for the changes and test them. |
So the blinds are not working, and some relays are having the same problem.
Debugging the web-interface from eNet I found out that the wrong uid is being called. For my blinds the "InputDeviceFunctions" is being called using the FT_INBA.SAPBP key. So every device has their own config and way of being called.
Luckily the interface can help us finding the right parameter.
On the server there is a xml file "https://192.168.10.90/ibnclient/conf/IbnConfig.xml?v=6.14.0&m=GIRA"
In this file there is a full list of all the devices. And more important a description of the channels.
And a language file "https://192.168.10.90/ibnclient/languages/catalog_language_en.properties?v=6.14.0&m=GIRA" that contains all the translations.
So my shutter controller device type is: "DVT_SJA1"
In this file: "https://192.168.10.90/ibnclient/languages/manufacturer_language_en.properties?v=6.14.0&m=GIRA"
I can find this line: DVT_SJA1=Top unit, blinds control button, 1-gang
In the IbnConfig I can find the following information for this device:
In the device info returned from the api we see the "channelTypeID": "CT_1F03".
We can then locate this parameter in the IbnConfig to find out the correct settings to control this channel:"
With this information we know how to control the channel:
So we need the parameters FT_INBA.SAPBP which translates to: SAPBP=Blind/shutter height
IFOS=Feedback, restraint
AND
IALFS=Feedback, lock-out protection
So yeah, it is going to be a lot of work, but with these xml files, we should be able to automate and make every eNet device work.
With recent announcement of integration into Mediola, I have lost every faith in ever getting a proper integration. So I think I will start working on this, but it will take some time.
The text was updated successfully, but these errors were encountered: