this is using the internal status of the last move (up or down) to tell HA the cover is either open or closed. Downside of using this is that one arrow will always be disabled, even when the cover is stopped halfway…
correct! In my NXT config, the relais are automatically disabled after one minute. So I’ve set this time for me at 55 seconds. This means that unless someone actively stops a cover, it will show to be in an end position in HA - for me this works perfectly now: both arrows available when a cover is stopped halfway, and the correct state is shown otherwise…
Can’t you fix this with setting an assumed state? I do that too with my covers on dobiss evolution system…
Then there is always an arrow , regardless the state
Cause I do it with a polling sensor , so if I stop the cover before the polling, and move it back, state could be wrong…
Allthough in theory it will never happen, since I now have a toggle function on my Niko buttons, finally!!
I had looked at that, but couldn’t find a way to use the ‘assumed state’ programmatically. When using template covers in a yaml file, that is an option, but not in a custom component (at least I haven’t found it).
I’ve created a release of the current stable version, which is v1.0.
This allows me to also create test versions on the dev branch on github.
So by default, HACS will suggest you to install a released version. However, if you want, you can switch to the dev branch as well (select Reinstall in the HACS configuration for dobiss):
With this, I’m actually looking for beta testers! I’ve implemented a first version of Timed Positional Covers, where you see and can set the actual position of a cover:
The way I’ve implemented it, is that it should behave nicely when the covers are operated outside of HA as well: I do update the assumed position in HA in that case, but don’t actually stop or move covers when the initial movement is not done through HA.
@tvds - this is what you’ve been interested in I believe
If you have tested this, please let me know if it works fine, or if you have any issues and/or suggestions!
Are the traveling time “up” and “down” related to the time settings in the NXT for activation of the opening/closing relais? Or isn’t there any correlation? Just to know if I need to change also these values in the Dobiss NXT itself.
In my case in my NXT, all my relais are configured to be active for 60s during opening / closing of covers. However in reality many of them only need 15-25s to fully open/close.
they are not related no, but the dobiss settings should be larger of course. The idea is that HA will manage the start/stop of the covers independently.
So to start using this, just leave the Dobiss NXT config to 60s, and put the exact times (I’d suggest to add 1 or 2 seconds though) in the customization for the covers in HA.
I’ve released v1.1 (https://github.com/kesteraernoudt/dobiss/releases/tag/v1.1) which includes the support for these timed covers. They are disabled by default, and can be enabled in the options. If you want to use them, enable them, and then customize the timings for each of your covers.
It does require you to get a dongle to connect to the P1 port. However, those that already have something connected to that P1 port, might want to look into the script I’ve created:
It allows you to use your existing P1 connection, and consumes the data coming from either a dsmr-reader server, or Home Assistant directly, and serves it in a form that Dobiss NXT expects it to be. I’ve created a docker as well that allows you to easily run this - info is on that github page as well.
I made some update (HA and dobiss) and now I have connection problem from HA to dobiss … I unistall the package dobiss and install again but it doesn’t work… I use the same IP and same API key as before, but I have a message “invalid authentication” …
Hi @bosjp - yes, I’ve seen the same. The dev version is already updated. I will create a new release shortly, but if you want, you can reinstall the integration through hacs and select the dev version now already. Apologise for the inconveniences, it looks like the jwt library changed it’s api, or maybe I’ve been using it incorrectly all along.
