Documentation initiative

It would be useful to look at Jsondb Configs by rkoshak · Pull Request #38 · HestiaPi/hestia-touch-openhab · GitHub which I hope will become the new baseline for configuration. This should speed up your tests as it reduces the boot time by two thirds (total boot time is around 10 minutes on an RPi 0 now, I’d guess around three minutes on an RPi and less than a minute on a more powerful machine).

Also, do you know anything about Ansible? It essentially works the same way that you describe (ssh to remote machine and configures it) only I find it’s way easier to manage and work with compared to plain old shell scripts. I do 100% of all the configuration of all of my machines with Ansible.

One thing you should definitely add to the script is the uninstallation of the Language Server Provider. You would ssh into the Karaf console and issue the following three commands:

  • bundle:list | grep -i language // take note of the number in the first column
  • bundle:list | grep -i lsp // take note of the numbers in the first column
  • bundle:uninstall // three calls to bundle:uninstall total

In Ansible it would look something like

- name: Get bundle IDs
  expect:
    command: /bin/bash -c "ssh -p 8101 openhab@localhost bundle:list | grep -i language | cut -d ' ' -f 1"
    responses:
        Password: habopen
  loop:
      - "language"
      - "lsp4j.jsonrpc"
      - "lsp4j"
  register: ids

- name: Remove bundles
  expect:
    command: /bin/bash -c "ssh -p 8101 openhab@localhost bundle:uninstall {{ item }}"
    responses:
        Password: habopen
  loop: "{{ ids.results }}"

NOTE: I just typed in the above, there might be a typo or the like. The first task gets the bundle IDs for the three LSP bundles that can be removed. The second task uninstalls the three bundles. “habopen” is the default password when logging into the karaf console.

It also would be interesting to see if the latest Mosquitto works out of the box since it comes with websocket support, freeing you from needing to create a custom build of the broker. This is on my list of todos but I’ve not had a lot of time to work on HestiaPi the past few weeks and I’ve still come diagrams and documentation to write for the above PR. I’m also awaiting some more feedback on the PR before I proceed too much farther.

Please accept my apologies for all this delay… This was not my plan but Covid-19 has really messed up my workload this month…

No apologies necessary. Being stuck at home does not mean we have more time to “play”. Personally, I have even less time than I used to before the schools were cancelled and I was forced to work from home. There is no hurry and I will be the first to admit, until some more people look at it and try to use it the new configs are probably not yet suitable for general use. An old saying goes “programmers are fundamentally incapable of testing their own code.” I did my best but I know how I expect it to work. There are assumptions I’m not even aware I’ve made.

Some of the errors and initial problems you experienced have me concerned and I look forward to figuring out the root cause and providing fixes where necessary. But there is no hurry what so ever. This can all wait as long as it takes.

If you haven’t figured out how to change the certificate someone over on the OH forums just posted a solution.

It’s a pfSense based tutorial but the commands should be usable. The key seems to be to recreate the p12 file with the right password.

1 Like

Here’s a small change I’d like to see to the Connect WiFi instructions. A step is missing (you need to browse the device’s IP address after connecting to the HESTIAPI network). I suggest the following (changes in italics):

As of 10.1 version (July 2018), you can now connect your phone to the “HESTIAPI” network with HESTIAPI as the password. Once connected, navigate to the HestiaPi’s IP address as shown on its screen using your phone’s web browser. Next, select your WiFi network (no hidden SSID supported yet) and enter the password. Your HestiaPi will restart to connect to your network and the HESTIAPI network will not be shown again if the details were correct.

Hmmm… most modern phones automatically redirect to that page. There is a chance the directive to the phone to redirect is not setup for a few seconds once the SSID “HESTIAPI” is advertised and you connected just then.
Please confirm the steps you followed and if you can reproduce if you wait 5-10 secs.

I tried connecting to HESTIAPI a couple of times and nothing seemed to happen. It’s possible I didn’t wait as long as 5-10 seconds. Unfortunately I can’t reproduce it now because I have already completed WiFi setup :slight_smile:

Following up on this: Today I went through the steps again (HestaiPi didn’t get back on my wifi after a power outage so I had to sign into my wifi again). I connected to the HESTIAPI network and waited about a minute but nothing happened. I had to browse to the IP shown on its screen to sign in to my wifi. Not a big problem but I wanted to make it known. If I ran into it, others may as well – so a sentence about what to do if the redirect doesn’t occur might make sense.

My phone is a Samsung running Android 8.0.0 FYI

Noted.
This is standard behaviour for phones when connecting to public WiFi networks that need signing up. Have you ever experienced such behaviour with that same phone?

I have in fact experienced this behavior many times when connecting this phone to various public WiFi networks. Only occasionally have I run into any such problems

Unless a user tries it too early I’m not sure how this can occur :thinking:

Thanks for the pointer, those instructions worked just fine. I thought I might be the only person who wants a CA-signed TLS cert for their smart thermostat, so it was fun to see that someone else was also trying to do this with openhab.

I’ve added this to the user’s manual and I tried to add it to the wiki, but I couldn’t figure out how to add or edit a page (and I was logged into GitHub). Pull request is submitted https://github.com/HestiaPi/hestia-touch-openhab/pull/55

Interestingly, Vanadium (a modified build of Chromium) still complains about the TLS connection because it uses AES256 in CBC mode. It’s a bit overly dramatic in my opinion, but GCM is better than CBC, so I’ll probably change the cipher at some point. That, however, is going to be a problem for another day.
Edit to add: And now Vanadium has stopped complaining… :roll_eyes: Whatever, I’m all good. :smile: