[Feature Request] Nuki-hub Stand Alone mode - have GPIO working when not connected to a network

[whale-av]

PROBLEM DESCRIPTION

A clear and concise description of what the problem is. GPIO control of the Nuki Lock only works when Nuki-hub is connected to a Wi-Fi Network. I would like the feature to work when Nuki-hub is not connected to a network.

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

• [x] Read the Contributing Guide and Policy and the Code of Conduct
• [x] Searched the problem in issues
• [x] Searched the problem in discussions
• [x] Searched the problem in the docs
• [x] Searched the problem in the chat
• [x] Device used (e.g., ESP32-S3): _____ESP32-S3
• [x] Nuki Hub binary firmware version number used: _____9.0
  • [x] Pre-compiled
  • [ ] Self-compiled
• [ ] Provide the output of http://nukihubIP/info:

### TO REPRODUCE
_Steps to reproduce the behavior:_
Connect Nuki-hub to a Wi-Fi network (just an access point with no other clients and no internet access): GPIO lock control works.
Re-start Nuki-hub without the preferred network available: GPIO lock control does not work.
Start the preferred network: Nuki-hub auto-connects and GPIO pins control the Nuki lock again.

### EXPECTED BEHAVIOUR
_A clear and concise description of what you expected to happen._
This is expected behavior except that GPIO works when Nuki-hub is connected to W-Fi without any MQTT broker on the network.

### SCREENSHOTS
_If applicable, add screenshots to help explain your problem._

### ADDITIONAL CONTEXT
_Add any other context about the problem here._
I noticed that if connected to a wi-fi network with access point isolation enabled the GPIO no longer works, suggesting that MQTT messages are looped back from the router when there is no receiving port open (broker not present).

That the GPIO function would work without a wi-fi network would be a useful feature for remote control of the Nuki lock by simple switches.
The Nuki-hub might also be impervious to any wi-fi attack in such a set-up, as both the SSID and password would need to be guessed if the ESP-32 wireless config can be set to not send the preferred SSID when scanning.
Starting the expected access point would still allow configuration when necessary.

**(Please, remember to close the issue when the problem has been addressed)**

[technyon]

I think this is a bug a not a feature request, it's not intended that GPIO depends on Wifi.

[whale-av]

Thank you for your reply. Could it be my fault... because I filled in the information for an MQTT broker address? Here is my config file.... in case it is my fault and the config causes the problem: nuki_hub.json.redacted.txt David.

[iranl]

@technyon: multiple GPIO related functions are part of NukiNetwork::update() which are mostly skipped when no mqtt connection is present/enabled. Does this need changing?

[technyon]

@iranl Yes, it's an oversight on my part, will have a look.

[technyon]

Hi,

I've checked and GPIO controls are working when disconnected ... except of course general input/output as those need a connected broker. What exactly do you mean by "connected to a wi-fi network with access point isolation enabled"?

[whale-av]

Thank you. I don't know what "general input/output means". My use is just to send a BLE command to open Nuki lock when GPIO 14 is grounded.

I cannot recheck for a while unfortunately, and this reply is too long, but... At first I tested with Nuki-hub connected to my home network.... with many clients connected. The GPIO commands failed when I disconnected Nuki-hub from that network, and restarted the ESP32-S3.

So for testing I tried to connect to an access point with nothing else connected. Unfortunately I had set the access point up for a specific purpose many years ago, and I could no longer access the nuki-hub configuration on that network, and no GPIO. First hurdle..... I had mac address security enabled.... so I disabled that. Still no config access and no gpio. Second hurdle.... that took a while to find... Access point isolation was enabled.

"Access point isolation" allows access for clients to the WAN, but does not allow any communication between clients on the LAN.

Removing Access point isolation allowed access to the config from my laptop and GPIO worked again. That is why I suspected that MQTT is looped back from the gateway if no client is found. GPIO is now working at the remote location with Nuki-hub connected to that access point, but with that access point turned off GPIO will not work. There has never been any web connection for that access point while testing, nor at the remote location.

Sorry for such detail, but it could be important for your analysis. David.

[technyon]

General input-output:

Which Nuki Hub version are you using?

[technyon]

@iranl As far as I can see, NukiNetwork::update() only processes the general input/output functionality of GPIO. Executing lock ations is handled in NukiWrapper / NukiOpenerWrapper, so a MQTT connection shouldn't be required.

[whale-av]

Nuki-hub version 9.0 Installed using web tool.

I don't have access at the moment..... I remember GPIO 14 (I have added an additional pull-up circuit) Input: Unlock: When connect to Ground, an unlock command is sent to the lock

[technyon]

@whale-av Let me know when you have access again. Also since it works for me, maybe try flashing the latest binary, maybe something has changed since the 9.0 releases:

https://github.com/technyon/nuki_hub/actions/runs/11426381208

[whale-av]

Thank you. I will do that, but it will be more than a week before I return home. David.

[whale-av]

I have brought the lock and esp32 home so that I can test. The nuki hub is updated to 9.01. I have reduced the configuration as far as possible, but the problem persists. I have attached the setup as reported when clicking the version number in the web interface. Thank you again for your help.. setup.txt

Logs from Nuki hub via webtool......

It seems that the "Restart ESP32 on network disconnect enabled: No" config setting is ignored.

wi-fi not present... so no GPIO as ESP32 reboots continuously after autoconnect timeout...

AND wi-fi present... so GPIO working as boot completes..

[iranl]

I've worked on this in #508.

You should be able to enable "Disable network if no connection within 60 seconds" from the http://nukihubip/advanced page (this page has no menu entry, you need to input it in your browser).

With this feature enabled the device should attempt to setup a network connection for 60 seconds. If it fails it reboots and disables all network features untill the next reboot (which can only be done by removing the power with the network disabled)

[whale-av]

Thank you. I updated to 9.02 and did see the advanced menu, but did not see the "Disable network if no connection within 60 seconds" entry. The main page still declared 9.01 so I assumed the update had failed, but now having returned to the web-tool installed 9.01 I know that it had installed because the "advanced" page is gone.. So I tried to update again to 9.02 and lost all contact with the ESP32 on the network. Back to 9.01 for now and maybe I should wait a while before trying again.

[iranl]

PR #508 is not merged yet and thus not in any beta or nightly

[whale-av]

I have OTA'd to 9.02 Beta3 Updater build: 11693590688.16.1 and ticked the "Disable network if no connection within 60 seconds" box in the /advanced menu. After a reboot GPIO does now work after 60 seconds when no network is available, and Nuki-Hub will connect again to the network after a power cycle. Thank you all... I will soak test before putting the hardware to serious use, but I cannot think of any reason that your solution will fail.

I was fooled for a while into thinking that it would not reconnect after a power cycle, as I had been using internet explorer to view the webpage, and that no longer worked. Firefox works fine with the new server page.

[iranl]

Good to hear!