[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