Skip to content
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

Map "continuous mode" ("Dauermodus") for Opener to a state topic and to binaryState #67

Closed
mundschenk-at opened this issue Jan 1, 2023 · 7 comments · Fixed by #296
Closed

Comments

@mundschenk-at
Copy link
Collaborator

Currently there appears to be no way to enable or disable "continuous mode" ("Dauermodus") for the Opener. Also when "continuous mode" is enabled, the "lock" created for the Opener is still shown in a "locked" state.

@technyon
Copy link
Owner

technyon commented Jan 2, 2023

Hi,

You can enable or disable CM (continuous mode) by sending the "activatCM" and "deactivateCM" commands. You're right this isn't yet reflected in the state, because of the strange way the bluetooth API signals this. Instead of changing the state it sets some bit somewhere else to show that CM is active - this could be easily mapped though by the ESP to reflect it in the state.

@mundschenk-at
Copy link
Collaborator Author

Ah, thanks I must have overread that in the documentation. Too me, ideally there would be a separate state topic for CM itself (which should be mapped to HA autodiscovery as a configuration switch) and it should be reflected in the binaryState of the lock to accurately reflect whether the controlled door is "(ring to) open".

@mundschenk-at mundschenk-at changed the title Add a way to configure "continuous mode" ("Dauermodus") for Opener Mao "continuous mode" ("Dauermodus") for Opener to a state topic and to binaryState Jan 2, 2023
@technyon
Copy link
Owner

technyon commented Jan 2, 2023

I think it still has to be handled via commands, because it interacts with the other commands ... for example writing "activateRTO" should disable CM if active.

If it appears as a seperate topic, it would imply this should work:

  • activate RTO
  • activate CM
  • deactivate CM
  • device switches back to RTO because it was active before

What would actually happen though it would switch back to "locked", which isn't very intuititive.

@mundschenk-at
Copy link
Collaborator Author

mundschenk-at commented Jan 2, 2023

Are you sure this is the way it works? I set CM via the official app and then activated and deactivated RTO via unlocking the lock entity in HA - CM was still active when I checked in the app. It appears to be a setting entirely orthogonal to RTO.

@technyon
Copy link
Owner

technyon commented Jan 2, 2023

Not a 100% :D. I'll do some reverse engineering to see how the firmware really behaves - it's not clearly stated in the documentation.

@mundschenk-at mundschenk-at changed the title Mao "continuous mode" ("Dauermodus") for Opener to a state topic and to binaryState Map "continuous mode" ("Dauermodus") for Opener to a state topic and to binaryState Jan 2, 2023
@technyon
Copy link
Owner

With the latest release it's not at least shown in the state node, and the binary state is updated accordingly. I'll have to see about adding a sensor, the API is quite confusing about this. It seems the NUKI App can indeed update CM and RTO independently.

@mundschenk-at
Copy link
Collaborator Author

Would it maybe be better to map the behavior of the HA lock entity to enabling/disabling CM instead of RTO (which has a maximum duration of 1 hour) for the lock/unlock services?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants