I want to make it easier to hack on the code that makes up a HestiaPi. In particular, I want automated testing, the ability to easily build an image from source, and so forth.
This should make it easier to make a change and ensure that it didn’t break anything. Maybe the change is a newer version of OpenHAB, updating to the latest Debian release, or removing things that don’t need to be there.
Qemu can emulate a raspberry pi, and that works well enough. I have an expect script to boot up an image, log in, change the default credentials, and then enable SSH. From there, all activities can be done over SSH. This will allow writing a setup script that should work on the VM or on hardware.
It’s been probably a year since I touched that code, but I would like to get back to it. The goal was to have it be useful for any raspberry pi based project, not just the HestiaPi.
So my main questions right now are: what are other people using for development? Install it on hardware? How do you make sure your changes will work on a fresh system (e.g., make sure you didn’t leave anything out from a commit)?
We usually work on a faster Pi (3 or 4) because we mainly touch the OpenHAB code while still need the hardware interaction, so VM or a PC won’t be enough.
Your point is very valid though and we would love to join forces but still life leaves next to no time for contributing on the project
If you are looking for repeatable and “configuration as code” type stuff look into Ansible. That is what I use to set up all my machines and VMs except for HestiaPi.
For HestiaPi I have a spare one that I use for development for similar reasons that HestiaPi indicated, there needs to be some hardware interaction.
I have run HestiaPi on a VM but in the end it was more trouble than it was worth. To test I’d manually inject sensor readings using the Karaf console or REST API and follow the logs to see that it did what it was supposed to. Then I’d check it in and pull on the “production” one and manually inject a couple of sensor readings and follow the logs there to make sure everything works as expected.
There is a lot on this front that can be done but, also like HestiaPi said, time is not abundant these days. But one of the higher priority things to do IMO would be to move to OH 3. There are some features on OH 3 that would make it easier to write unit tests right there in the rules (i.e. Script rules).
I feel like I owe an apology, or maybe not, but I want to set something straight.
For the last so many months I kept promising myself to deliver this or move the project to that next step and there was never enough time to even do the minimum to mark it as a mini-step.
It may look like the project is on hold all this time (code commits, PCB/Case releases) but this is certainly not the case for my interest and passion towards improving the software and hardware points we have all mentioned and brought to everybody’s attention.
Something good that I keep reminding myself we could all take from the covid situation is that we got enough time to “think” rather than “make”. This has been helpful regardless of covid or HestiaPi in my life as “rushing” to development sometimes overshadows a possible culprit down the line… Similar to like they say, measure 10 times, cut once. Eh, we have measured more like 100 times by now
(another separate post on the way with an overall update)
