Using the OpenHAB mobile app (Both Android & IOS) connected local or remote displays the site map correctly. When connecting the app remote to my self hosted myopenHAB none of the switches (Control lights) work, on the local connection they work fine as well as previously on myopenhab.org. In the openhabcloud.cfg “mode=remote” is set. The Android app notifies “event subscription failed, widget refresh maybe impaired”, this is the only indication on an error as I have not found any obvious errors in the logs. On the webpage of myopenhab I see my Android device, can send notifications to the device and access my openhab dashboard remotely.
During installation had the following warning:
npm WARN bcrypt-cache@1.1.0 requires a peer of bcryptjs@^2.4.3 but none was installed.
npm WARN grunt-qunit-node@0.1.0 requires a peer of qunitjs@^2.0.0 but none was installed.
System setup:
Openhab and myopenhab in a separate Proxmox LXC containers running Debian 10.
The frontend uses SSL offloading, the backend I tried both to http://myopenhab.a.b:3000 and https://myopenhab.a.b (myopenhab Nginx install uses same SSL cert on local LAN) with same result. For internal routing the DNS resolver has host override for myopenhab.a.b
I am not familiar with PFsense logs but according to the 200 code this looks like the access is not blocked but gratend, right.
What does the openhabcloud log show while you try to access the site map ?
E.g.:
/var/www/./openhab-cloud/logs/audit-2020-06-18-process-3000.log
EDIT: Was stuck on empty log file until I figured out that log and config.json were owned by root, that fixed finally have audit logs with content. Comparing the logfile noticed that mine was showing “Undefined” instead of the IP address as in yours. Made the mistake of pointing internet traffic coming out of HAProxy to to http://myopenhab:3000 instead of https://myopenhab. That fixed the result of an on-off-on action now shows as follows but no joy yet:
2020-06-22 22:46:44:4444 audit: me@dom.com | online | GET | /rest/sitemaps/events/33e0569d-5356-4a06-b579-4bd3e5fa875b | 172.16.1.1 | myopenhab.dom.com | openHAB client for Android
2020-06-22 22:46:44:4444 audit: me@dom.com | online | GET | /rest/sitemaps/events/2556d7d2-abe6-4f56-ac1b-1ba46c799f31 | 172.16.1.1 | myopenhab.dom.com | openHAB client for Android
2020-06-22 22:46:47:4747 audit: me@dom.com | online | GET | /rest/items/OUTCurtFrontUpLIV | 172.16.1.1 | myopenhab.dom.com | openHAB client for Android
2020-06-22 22:46:48:4848 audit: me@dom.com | online | GET | /rest/items/OUTCurtFrontUpLIV | 172.16.1.1 | myopenhab.dom.com | openHAB client for Android
2020-06-22 22:46:49:4949 audit: me@dom.com | online | GET | /rest/items/OUTCurtFrontUpLIV | 172.16.1.1 | myopenhab.dom.com | openHAB client for Android
Did see some other message restarting the openhabcloud service:
Jun 22 21:03:11 myOpenHAB systemd[1]: Started node.js openhab cloud server.
Jun 22 21:03:13 myOpenHAB openhabcloud[25585]: Option polling duration is not valid. Please refer to the README.
Jun 22 21:03:13 myOpenHAB openhabcloud[25585]: (node:25585) DeprecationWarning: current URL string parser is deprecated, and will be removed in a futu
Jun 22 21:03:13 myOpenHAB openhabcloud[25585]: (node:25585) DeprecationWarning: current Server Discovery and Monitoring engine is deprecated, and will
Jun 22 21:03:13 myOpenHAB openhabcloud[25585]: (node:25585) DeprecationWarning: collection.ensureIndex is deprecated. Use createIndexes instead.
Not sure if the second line about polling is an issue?
And in the openhab-cloud-date-process-3000.log I see the following:
cancel restRequests that have become orphaned. For some reason neither close
nor finish is being called on some response objects and we end up hanging on
to these in our restRequests map. This goes through and finds those orphaned
responses and cleans them up, otherwise memory goes through the roof.
So it looks like it’s more or less normal that there are orphaned processes.
With regard to polling: Did you have a look to the README file ?
I haven’t been able to find a readme on the system that contains the polling duration, only location I found is in the app.js where it is set to 300. Changing this to 3, 30 and 30,000 did not change the error reported.
