Documentation initiative

General
#13

I wish I had thought of the superglue idea.

I’ve something else to add to the list of issues. Don’t choose a screw with a large head. I was lazy and didn’t want to install a wall anchor and I’ve a box of random screws so I picked a larger diameter screw. That was great for attaching the plate to the wall but the head was also bigger and now the case won’t seat properly at the bottom. Guess I need to install that anchor after all.

In BasicUI it’s under Settings → Maintenance.

image
image2175×620 71.5 KB

NOTE, I’ve got my instance configured with restoreOnBackup and Last Backup is one of the Items that is restored which is why this screen grab is showing something there. I’m rebooting so Items like the version Items haven’t been populated yet.

The Rule that runs to call that script is defined at around line 800 (I’ve made a bunch of changes so can’t be precise, the Rule name is BackupCommandChanged.

From there I was able to discover that backup script (after creating the above post) where I could see that it just calls openhab-cli backup). I would like to see the Mosquitto config and the UI config added to that script. I’d also like to see it save to another folder and keep the last X backups, but baby steps. :wink:

From looking at the Rule, it turns the heat on for 10 minutes or until the target temp is reached, which ever occurs first. It’s entirely possible that you can push boost and nothing happens if you are already at or above temp. I don’t think this is expected behavior (at least it wasn’t for me) but the change would have to occur in the rules. I expected exactly what you did, that it would turn on for 10 minutes regardless of the current temp.

If you have any questions ask away. I am somewhat of an OH expert so I can probably answer any question you have to ask except for “why” questions (e.g. why is it done this way instead of that way). Start by reviewing the Concepts section of the OH docs though. It will give you a bit of a foundation to understand what you are looking at and where stuff is defined.

If at all possible it is best to set that at the router by defining a static lease for the HestiPi’s MAC (which is nicely displayed both on the screen and in BasicUI). Failing that, look on an RPi forum and I’m sure you can find a tutorial to help.

That’s really what I was after as well. I can figure it out (and mostly have at this point) by looking at the OH configs. Many users will not so gotchas like how Boost seems to work and the behavior of the Fan mode needs to be described in docs.

No, don’t use the embedded broker if/when updating to OH 2.5. Moquette is no longer maintained by upstream. It might work just fine for this application or it might not. If not there’s nothing anyone can do about it. So stick to Mosquitto. A 2.5 instance of HestiaPi should look exactly like it does currently, from a functional perspective.

Once I have hysteresis working right that’s going to be pretty high on my list to try out.

Note, in answer to one of my questions above, running an apt upgrade will upgrade OH to 2.5, so don’t do it, at least for now.

That’s what I expected at first. As it was written in the Rules though, it’s was kind of pointless if you are in the US mode. There is no hysteresis so the temp is always going to be within 1 degree F of the target (assuming it’s cold and you need to run the heater to maintain temp). Because Boost cuts out once you reach the target temp it pretty much only does what AUTO is already doing so there is really no point. I expected it to just run for the boot time or until it was set back to AUTO or OFF.

#14

Having a Pi 3 or so with both ETH and WLAN would be the best approach, but you knew that already ;). Also if you plan on experimenting, the same SD card can run on a Pi 2/3 for speed purposes. LCD, relays, temp sensor don’t cause much of a problem if missing on your dev setup.

#15

I guess it makes more sense for houses where heating is not ON most of the time so that it turns OFF after x minutes. If AUTO was already the previous state, then yes, it makes no sense. I totally see your point and it is getting more supporters :wink:
Added an issue to myself for this:

#16

Another day, another PR. :smiley: I got the static IP address documented and started in on getting TLS set up. Life is going to get busy for me this week, so it might be a while before I get any more updates written up. When I get to updating the section on physical installation, I’ll mention the bit about a dab of superglue to keep the rivets in place.

I realize that setting up DNS and TLS on a HestiaPi is not a very common use case, but the nice thing about volunteer work is that I can work on whatever is important to me. :laughing:

If there’s an open issue on GitHub about improving the backup scripts, let me know. That’s on my list of contributions to make in the future. If someone beats me to it, I’d be happy to do code review.

#17

Hey, thank you for your PRs! I just merged it.
We are focusing on optimising our hardware for (mass) manufacturing right now so our time on coding, new features etc is limited for about a month too :frowning: but it is for a good purpose (hint: no superglue will be needed any more). I’m happy to review and merge your work whenever you get time!
P.S.: Can you please change your username as it may confuse people about who is who?

#18

I’m working on setting up TLS for the service running on port 8443 (not Mosquitto, which appears to be the service which deals with MQTT messages). I’m having trouble finding the configuration which stores the password for the Java keystore. Let me explain what I’ve found so far and I’m hoping someone can point me in the right direction for where to find this password.

The OpenHAB docs explain that a self-signed certificate is used by default. This is good and will work for the vast majority of people, but some people might want to change it. It identifies the location of the keystore as $OPENHAB_USERDATA/etc/keystore. The variable is defined in /usr/lib/systemd/system/openhab2.service as being /var/lib/openhab2 and there is a keystore at /var/lib/openhab2/etc/keystore. So far so good.

Next, I wanted to take a look at what is in there before I go messing around with things. The Java keytool is not in $PATH nor is it in a standard place (which is fine, and I’ll just document these things). I wanted to list the keys, so I ran this:
/opt/jdk/zulu8.40.0.178-ca-jdk1.8.0_222-linux_aarch32hf/bin/keytool -list -v -storepass changeit -keystore /var/lib/openhab2/etc/keystore

The password changeit is the default password for Java keystores, and I even found a closed issue reporting that openhabian didn’t change it from the default and it was effectively closed as WONTFIX because the tiny security gain isn’t worth the effort. However, when I run the command above, it says the password is incorrect.

Surely this password must be in a configuration file somewhere, because the webserver on 8443 is reading its certificates from somewhere, but I can’t find it. I found /usr/share/openhab2/runtime/etc/jetty.xml that contains a value for jetty.ssl.password, but that password doesn’t work, and it also points to /etc/myKeystore which doesn’t actually exist, so I’m guessing this config file isn’t being used?

The OpenHAB docs say that Jetty is included as the HTTP server, so it seemed promising. I think I’d be able to troubleshoot this far more effectively if I understood how OSGi, Apache Karaf, Eclipse Equinox, Jetty, Mosquitto, and whatever other components make up OpenHAB fit together. The OpenHAB docs mentions the technologies, but then the “concepts” section of the docs do not mention any of these components. I also checked the Developer Guides and Developer Appendix and couldn’t find a software architecture diagram for all of OpenHAB there either.

Another way I might be able to piece together these things would be to build an image myself and flash it onto a pi. I see that is described on the wiki now, but I’d really rather wrap up the task of getting TLS set up on my system (and documented).

P.S.: I like my new username :smiley:

#19

openHAB runs on Karaf which in turn uses OPS4J Pax Web to configure the web server. Beyond that though I hit a dead end. I can’t figure out where and what the password for the existing keystore is.

But do not confuse the Karaf keystore with the JVM keystore which that issue you linked to refers to. Karaf has it’s own keystore independent from the JVM so changeit would almost certainly not be the correct password. There is supposed to be a property in org.ops4j.pax.web.cfg with the password but it’s not there. I also saw some activity where the password has been moved and encrypted so it doesn’t have to exist in plain text. Without spending more time I don’t have right now I’m afraid I don’t have any other ideas except to look at the environment variables that OH set up.

That is all a whole lot of to learn. OSGi isn’t a thing so much as it is a way to package and develop modules that can be combined into an application. Karaf is the OSGi container that takes all the OSGi parts that make up openHAB and runs them. Much of what makes up OH is actually just inherited from Karaf, including Jetty, so for this stuff you need to be looking at the Karaf docs for the information you are after and the sorts of architecture data you are after.

Mosquitto is a wholly separate program and it is not part of openHAB. It’s one and only job is to be an MQTT broker.

#20

I’ve started putting together some scripts which will automatically SSH into a fresh Rasbian system, and make it into a HestiaPi. This is from SSHing in and changing the default password, to downloading and building websockets and mosquito, installing systemd scripts… the whole thing.

In order to make this be easier to test, I set up a Rasbian image under QEMU so it’s easy to test the script without having to fiddle with hardware. Obviously this has its limitations, but it’s able to find things like “compilation errors” very quickly. I’m also attempting to use newer versions of software where I can (e.g. buster instead of stretch, which forces using the latest mosquitto, and so on). That might be a mistake, but if I get it working, then we will have a path forward on getting things updated. It wouldn’t address the ability for one to update their own HestiaPi, but it would at least make fresh images easier to build.

…and I’m doing all of this, so I can figure out how to add TLS to my HestiaPi and then document that.

I’ll keep plugging away. Here’s where you can see how far I’ve gotten: https://gitlab.com/hestiahacker/raspberrypi-automation/-/tree/hestiapi

#21

It would be useful to look at https://github.com/HestiaPi/hestia-touch-openhab/pull/38 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.

#22

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

#23

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.

#24

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
#25

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.

#26

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.

#27

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:

#28

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

#29

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?

#30

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

#31

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

#32

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: