Closed pixelwave closed 1 week ago
Not a bug. This is by design. Relevant code:
/**
* connected() is called every time the WiFi is (re)connected
* Use it to initialize network interfaces
*/
inline void connected() override { InitHtmlAPIHandle(); }
I am not an expert .. is it possible to change that behaviour? What file do I have to change so I can also use the multirelay HTTP Api even when in AP-mode?
Also do not quite understand why this is by design? Since the standard WLED HTTP calls do work even in AP mode. Just not the multi-relay ones…?
JSON API
Also do not quite understand why this is by design? Since the standard WLED HTTP calls do work even in AP mode. Just not the multi-relay ones…?
You are welcome to implement...
Ok so no chance without major changes?
But is there an explaination why only the usermods/multirelay http requests do not work in AP mode? If you say it is by design…?
Trying to understand and learn …
Ok the JSON API seems to work even when in AP-mode. Now I need to rewrite the remote controller script for JSON commands. Previously with my HTTP API approach I was relying on the status request command to update the remote controller UI "Status Request: http://[device-ip]/relays".
This command does not seem to be available in the JSON API (https://mm.kno.wled.ge/usermods/MultiRelay/).
I still do not quite understand the "design decision" to not allow HTTP requests from the usermod, but standard HTTP requests, JSON requests etc are all allowed in AP-mode?
Feels more like a bug than a "feature" ...
If you are using MM then open an issue there. Also you can, as already said, implement the functionality yourself. I have no intention of doing so.
If you are using MM then open an issue there. Also you can, as already said, implement the functionality yourself. I have no intention of doing so.
What is "MM"?
Also you can, as already said, implement the functionality yourself.
As stated before I am no expert. I am usually trying to cobble together some code and am happy if stuff works. ;) Everything worked fine in this project until I switched to AP-only mode and encountered that - for my understanding - weird behaviour.
I have no intention of doing so.
Also I am not pushing you to implement anything. I only asked if it is maybe a simple line comment / uncomment in the current code. But when you mentioned it being a deliberate "design decision" I was just trying to understand the logic behind. Because it is a decision that imo makes no sense at all - but maybe I am missing something ...
Hey! This issue has been open for quite some time without any new comments now. It will be closed automatically in a week if no further activity occurs. Thank you for using WLED! ✨
What happened?
If I connect a WLED ESP32 to a Wifi Network and then try “192.168.178.59/relays?toggle=1,0,1,0” it works!
But it does not seem to work if the WLED ESP32 is in “AP-Mode” (4.3.2.1/relays?toggle=1,0,1,0).
For my final deployment I have the WLED ESP32 not connected to any Wifi network just acting as its own AP.
It seems to be an issue with the “multi-relay” usermod implementation. Because the standard HTTP commands from WLED (like “4.3.2.1/win&A=255”, etc…) work when connected to a Wifi Network as well as in “single AP-Mode”.
To Reproduce Bug
Put WLED in AP only mode and try to send HTTP request “/relay“ or “/relays?toggle=1,0,1,0“.
Expected Behavior
Get response / toggle relays.
Install Method
Binary from WLED.me
What version of WLED?
WLED 0.14.3
Which microcontroller/board are you seeing the problem on?
ESP32
Relevant log/trace output
No response
Anything else?
No response
Code of Conduct