Receive messages sent, while NukiHub was offline

[dhorak1]

Hi,

first of all: Thank you for this great piece of software!

when NukiHub is used in less reliable networks, it might be offline sometimes, when new MQTT-messages arrive. Currently, as it seems, those messages won't be received (my guess: they are "masked" by the persistent messages NukiHub publishes on most topics).

While it might be okay (or even desired) to lose messages on some topics (like /lock/action - those probably shouldn't be executed with an unpredicable delay), it would be great, if NukiHub could handle delayed messages received on /keypad/command/*-topics, since the sending party otherwise has to implements some kind of timeout-and-retry-logic to ensure, that sent keypad-commands are actually executed (which is error-prone and kind of contradicts the asynchronous nature of MQTT).

[technyon]

Hi,

I'm not exactly sure what you mean by delayed messages. Whenever an action is received, it's executed. The only exception is that the first messages after a reconnect are ignored - this is a security feature so that the door doesn't open minutes or hours later because the wifi was out.

[dhorak1]

The term "delayed" was a bit misleading. What I meant here are messages, which were sent while NukiHub was offline (and therefore are received with a delay on the next reconnect). Specifically: Messages sent to the /keypad/command/-subtree for adding, modifying or deleting keypad-codes. It would be great, if NukiHub could receive and process messages on these topics, even if they were sent during a network loss.

Speaking of the /lock/action-topic: Ignoring "delayed" messages on this topic makes totally sense.

[technyon]

Hi,

sorry for the late answer, I lost track of this issue. As mentioned before, ignoring those messages sent when NUKI Hub is offline is by design. You don't want security related things to happen three hours later because Wifi was down while you sent those commands. I think the solution is to monitor in your scripts if those commands are executed in a reasonable amount of time, and if not resend them.

[dhorak1]

Hi,

now I almost forgot about this ticket too. :)

As in the case of lock actions (in particular unlock/ unlatch), I absolutely agree with you. You definitely don't want such a command to be executed at some random later point in time.

However, I don't think this necessarily applies to keypad commands: If you add, modify or delete a keypad code, it doesn't really matter WHEN it happens. It is only important THAT it happens - especially when it comes to modifying and deleting keypad codes, since code-owners otherwise would keep access to your property, when they shouldn't have anymore.

Of course, you could also monitor the transmission/execution through the client and resend the command after a certain time. In my opinion, however, this makes little sense, as MQTT already provides a suitable mechanism natively with the QoS functionality.

[technyon]

@dhorak1 At this time, any MQTT messages after reconnect are ignored. Filtering for specific messages would require a more sophisticated approach. Not saying it's impossible, but it would need some effort to implement and especially to test. First of all, it would need a definition of what and what not to ignore.

[github-actions]

This issue has been automatically marked as stale because it hasn't had any activity in the last few weeks. It will be closed if no further activity occurs. Thank you for your contributions.