Hestia Hacker

@hestiahacker
88 Followers
12 Following
246 Posts

I am the primary maintainer of the #HestiaPi (hestiapi.com), which is an #OpenSource thermostat. I also build and sell the hardware to make the technology more accessible. #privacy #foss
https://www.tindie.com/stores/eternalsunshine/

If you like what I do, please consider speading the word, buying a unit, or sending me some digital currency. The software maintenance alone is a ton of time & effort and hardware sales barely break even.

#Anticapitalism #Degrowth

BTCbc1pz4pzdvqdq0e7qv49fkrs2ngsf77d5yukh4seudemejp5g8039e0qrtt0la
old BTC address18qPnje9WPbgGxkqT8d5WEBXTfV9LocMTG

The latest release of the #AirGradient firmware removed the code that phones home to the company servers even when you check the to to explicitly tell it not to do so. This is a big win for #privacy and #SelfHosting!

https://github.com/airgradienthq/arduino/releases/tag/3.2.0

I plan on flashing this onto my device and testing it to verify nothing was missed. #tcpdump and #wireshark are my friends. ๐Ÿ˜„

#security #cybersecurity #infosec #OpenSource #OpenHardware #electronics

Release Release 3.2.0 ยท airgradienthq/arduino

What's Changed Fix invalidate value check for getAverage function by @samuelbles07 in #275 Fix display 0 measurements value on boot by @samuelbles07 in #281 HTTP client failed/timeout to establish...

GitHub
Instructions has been merged into the development branch. I've submitted a PR to add some text about how to contribute back to the project.

This doesn't have anything to do with the #HestiaPi (yet ๐Ÿ˜‰), but AirGradient is one step closer to fixing their compilation instructions.

This is exciting news because once their code is modified to stop phoning home to the company's server, I plan on adding documentation to the HestiaPi project on how to configure the #AirGradient ONE to act as a remote temperature and humidity sensor.

If you've ever had a #thermostat mounted too close to the door, you understand why this is important.

If this is the kind of project you want to support:

1. Build or buy a #HestiaPi
2. Tell your friends
3. Contribute: bug reports, beta testing, documentation, code, answering questions on the forum, or building hardware for others (we don't currently accept monetary donations)

I have been supporting this hardware for over 5 years now and want to keep doing so as long as I can.

Having more people contribute makes it easier. Having more people buy hardware let's me buy in bulk & cut prices.

I've spent a lot of time not just thinking about this, but living it. I've had the core of the #HestiaPi (#OpenHAB) abandon support for all versions of Java that can run in a Raspberry Pi Zero W. ๐Ÿ˜ฉ

So now our project is at a crossroad. How do we proceed? It'll run on the Pi Zero 2 W, but what about all our original users who have a pi soldered onto their PCB?

I think I see a path forward that will let still use the existing hardware & OpenHAB. It'll be a lot of work, but I think we can do it.

#RaspberryPi may have their own problems, but they've been solid on supporting both their #hardware and #software.

They even publish a minimum number of years they are going to keep producing each model of hardware. This allows projects to plan around that, which gives rPi a leg up when it comes time to decide which hardware to use.

I hope you enjoyed my reflections on the state of long term support and comparing commercial IoT to #OpenSource #IoT.

LTS for hardware is brutal. CPUs get discontinued all the time. The same is true for small board computers (SBCs). For example, the oDroid SBCs looked promising but they never got their kernel patches upstreamed nor did they port their patches forward to newer kernels. So you could only run them with an old kernel that's no longer supported. They ended up abandoning those models of hardware all together. Now they have new models. How long do you think they will support those? Probably not long.

What can be done about the #OpenSource world to make things more #sustainable?

The biggest thing, by far, is to make things as simple as possible! That means you will inherently have fewer dependencies.

Depend on libraries that have long term support.

Contribute upstream whenever possible. Mainly code, but if you are selling #hardware, money too.

So what can help with the long term support (LTS)?

There's really no helping the commercial world as long as they're trying to make a profit. The limited exception would be companies who not only make this their central business model, but also establish a track record of delivering on that promise. There are almost no business who have managed to pull this off. They used to be more common, but people are either unwilling or unable to buy the higher quality stuff these days.

In the case of #OpenSource projects, it's a little different, and some projects are great at long term support. The challenges are that the #software and hardware that they depend on frequently stop getting supported. At that point, do they spread people thin to stay doing long term support for all the things they depend on?

If it's #hardware, that's probably not an option even if you have dozens of volunteers.

It's still a cost problem, but the cost is people's time, not #money.