"Visit Panel page" in Panels context menu goes to http://172.17.0.1/

[eelco2k]

After succesfully running the docker container:

docker run --name nspanelmanager -e TZ=Europe/Amsterdam -v "./data/":"/data/" -d -p 8181:8000 -p 8001:8001 --restart always nspanelmanager/nspanelmanager-amd64:latest

(i've changed public port to 8181)

My NSPanel comes up, my router gives the NSPanel for example 10.0.0.34 IP, but then I use the "Visit Panel page" it uses some docker internal IP range i guess...

also going to http://10.0.0.34/ does not work and i do see i receive html file and index.js and index.css ... but there it ends i never get a full page response...

when it wants to get jquery.min.js and bulma.min.css it does not return a response. although they are in the html response:

  <script src="/static/jquery.min.js"></script>
    <script src="/static/index.js"></script>
    <link rel="stylesheet" href="/static/bulma.min.css" />
    <link rel="stylesheet" href="/static/index.css" />

when i retreive the whole url via http://10.0.0.34/static/jquery.min.js there is no problem getting the response....

NSPanelManager Version 0.0.1487

[aaronouthier]

You are not running the docker container correctly!From your linux prompt, you need to clone the entire repo, then cd into it, and cd onto the "docker" subfolder/subdirectory. There, you'll find a few .sh scripts. Run the "./docker-build-and-run.sh" or similar to create and run the container.If any other method is supported and working, I have yet to hear of it (not impossible).--AaronSent from my iPadOn Oct 8, 2023, at 1:33 PM, Eelco @.***> wrote: After succesfully running the docker container: docker run --name nspanelmanager -e TZ=Europe/Amsterdam -v "./data/":"/data/" -d -p 8181:8000 -p 8001:8001 --restart always nspanelmanager/nspanelmanager-amd64:latest

(i've changed public port to 8181) My NSPanel comes up, my router gives the NSPanel for example 10.0.0.34 IP, but then I use the "Visit Panel page" it uses some docker internal IP range i guess... also going to http://10.0.0.34/ does not work and i do see i receive bulma.js files... but there it ends i never get a full page response...

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[aaronouthier]

Disregard! In page 4 of the manual, it does say to download the repo, but then it says to start the docker container in a manner identical to what you wrote.

Seems I am doing it wrong!

[eelco2k]

@aaronouthier this has nothing to do with the nspanelmanager docker container.. I think because my other issue: #96 the NSPanel startup sequence is not fully ready so therefor the webinterface is also not ready yet.

see: main.cpp @ line:155 where the webserver gets started.

i havent figured out where the LOG_ERROR() can be found.

[eelco2k]

Okay, after looking at registering a new nspanel method with a HTTP POST to /api/register_nspanel, i found out that when doing this request in POSTMAN, with this json data:

{
    "mac_address": "C4:DD:57:11:11:11",
    "friendly_name": "NSPANEL1",
    "version": "0.0.1487",
    "md5_firmware": "7a76e44ad044a01b056fbb9a77bfe008",
    "md5_data_file": "c61d187705a35a9ed3264b311e18a39c",
    "md5_tft_file": "b4c39ac1b49ea209ba089729b86b060c"
}

I get an OK response, so far so good. But because i called this endpoint via my local machine now the "Visit panel page" is the IP of my Client Request IP. so that is how it retrieves the IP address. So what i found was that my iptables for DOCKER were not correct:

sudo iptables -t nat -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
sudo iptables -t nat -A PREROUTING -m addrtype --dst-type LOCAL ! --dst 127.0.0.0/8 -j DOCKER

as a quick hack, i opened the sqlite db, changed ip_address column in web_nspanel and restarted the docker container.

furthermore because i did not upload the gui.tft via the webinterface the md5 hash was empty in the sqlite database. so i also did a md5 gui.tft in my terminal to get the md5 hash.

So that fixed the problem. But unfortunally the webinterface of the NSPANEL itself (not nspanelmanager) is still not reachable...

[tpanajott]

Hi!

Some good tinkering I can see and you are correct in all your statements in how it receives the address and so on. We are currently reworking the registration process where the panel itself will report its own IP during the registration which would hopefully solve that issue. Regarding the web interface though, that is a known issue and work is being done to resolve it though it's not currently ready.

Am I correct to understand that you did manage to get it working?

[eelco2k]

Well I have the NSPanelManager to work, but no commands to the NSPanel work unfortunately. that is because the NSPANEL itself doesnt start the webserver. and also does not start the websocket connection to the NSPanelManager. the NSPanel only displays: "Registering to manager..." after it connects to the wifi.. (i see NSPanelManager and NSPANEL are both connected to MQTT broker) so the NSPANEL must have wifi connection.

but the issue as defined: "Visit Panel page" menu item now shows correct ip (by editing the Sqlite db column).

[eelco2k]

my MQTT log topic of my NSPANEL shows this two last errors:

C4:DD:57:11.11.11;INFO; RoomManager.cpp:171 f(.loadAllRooms) Getting config for room 1 
C4:DD:57:11.11.11;DEBUG; RoomManager.cpp:183 f(.loadAllRooms) Calling roomChangedCallback

[tpanajott]

Yup, but the commands are sent over mqtt which it connects to as you say, though if I remember correctly it doesn't start to listen to the commands topic until it has registered to the manager.

I see you have a segment LAN with firewall rules between them, can the panel itself initialize HTTP-reqest to the manager? The registration is a HTTP POST (I think, might be a GET-request) to the manager.

But, as (I think) you also mentioned you do not have the websocket connection working? All the commands sent from the manager to the panels is sent through the websocket out to MQTT. The panel should still be able to register even you can't connect to the websocket.

[eelco2k]

I think something goes wrong with the webserver.. as the endpoint on port 80 is also not reachable. @main.cpp line: 155 webMan.init(NSPanelManagerFirmwareVersion); gets invoked... but this fails i guess. and because it's a single threaded application (i assume...) the rest of the code won't get executed...

on the NSPanelManager webserver side (python) in web/api.py @ line 238 you filter on sqlite -> web_nspanel table , column: mac_address, (that has not changed, so it should return "OK" status 200, (even tested it on both on different VLANS)

Which works cause i tried this with POSTMAN and the endpoint does update the data. and returns OK.

shouldn't the small webserver on the NSPANEL itself be a dedicated process instead of starting it via a function like: taskManageWifiAndMqtt() (and therefor in the same process/thread)?

[tpanajott]

Well, the ESP32 really one have 1 usable core to play with and in my testing you need to initiate the websocket after WiFi is established for it to work though that part could use some work. If you know of any other better library for serving a web interface from the ESP32 I'd gladly take a look at it as the ESPAsyncWebserver which we are using currently has given us lots of problems.

Part of the problem it seems is that the bulma files are quite big. I'm currently working on stripping down the bulma css to only the CSS we need but, then again, that will come with the (hopefully) soon to be released beta version with the updated MQTTManager and firmware to go with it.

[eelco2k]

Only found this one: https://github.com/philbowles/H4AsyncWebServer not sure if this package resolves the issues though....

[eelco2k]

Okay, i think i found something more about the issue. the NSPANEL webserver was not starting anymore because i had the setting: "Default page" to "Room page", when set it back to "Main page" i get port 80 working again, but the bulma and jquery still wont get downloaded in chrome, but now in Firefox all works. (but a few refreshes on firefox and the webserver crashes again...) it looks like its really flaky :´(

[eelco2k]

I think i can close this for now as the solution for this initial issue is resolved by the docker iptables.

[tpanajott]

Only found this one: https://github.com/philbowles/H4AsyncWebServer not sure if this package resolves the issues though....

That looks really good, I'll have to take a look at it but unfortunately yes, the web server as of now is really flaky and does need more work.