Also, if anyone is looking for projects on the device side for their OpenHAB set up I can supply firmware and either schematics or modules and wiring diagrams for things that produce data like this, which is the temperature of my heating loop IN and OUT pipes.
One potentially useful feature of this is that it allows you to not just switch the heating on, but to control the temperature of the heating loop, rather than using the boiler to do so, facilitating altering the running temperature dynamic based on conditions rather than changing the boiler settings.
The final run on this graph is the heating being limited to 40*C by automation.
You proved my point.
You have been connecting and assembling things using multipurpose components. Linux from scratch still used the Linux kernel and GNU programs.
OpenHAB similarly lets you assemble a Smart Home management solution either using prefab bindings or your own ones.
That’s fair enough. It was a deliberate choice for openHAB, to take advantage of portability. You can host it on any platform … barring the puniest hardware, that’s the cost of that choice.
Many if not most openHAB users run on RPi, there’s even openHABian to provide a readymade OS image. Well there cannot be a definitive figure in the docs because openHAB is so modular.
But it works for almost everybody to use the Java defaults which on a (32bit) RPi is 256 MB.
You and I certainly have differing opinions on if that’s “lightweight”, but it just doesn’t matter as long as that runs well on a RPi, and it does: short of bugs to cause mem leaks there’s still headroom in CPU and even RAM. So why should I care if the implementation is “lightweight” ? To feel happy that I can do better ? openHAB is a not a programming contest, as someone already wrote it’s a tool, an enabler to all home automation users.
Once more, please answer my question way up: what is the purpose of your posts ? What do you want us to answer or realize ? Or do you just want to hear that you can do better ? Of course you can.
I’m not even sure I should reply as you point is a bit miss guided at best.
If I want beans and toast I can grow and harvest tomatoes, beans and wheat, cook and soak the beans in tomatoes… mill the grain, make bread, milk a cow and make butter, or I can buy a loaf of bread, a tin of beans and a block of butter and make it all 100% myself. Or… I can subscribe to a ready meal mail order company who makes dozens of different meals so I don’t need to cook anything and have many, many options for different meals if I choose.
I don’t want ready meals I want homemade, but … I don’t want to grow my own produce, I can buy the ingredients. I don’t want Chili con carnae or Chicken Supreme I just want beans on toast! So why would I sign up to the mail order company when they don’t make what I want and the rest of the stuff it comes with is useless to me?
So with your logic it’s one or the other. 100% from scratch or 100% off the shelf. There are middle grounds and very valid and useful reasons to pick a point in between that provides the right amount of flexibility and the right about of overheads.
And just to add, even though it’s possibly inflamatory, but I don’t believe you understand how Linux works, it’s not like Windows, you don’t just double click install each program and be done.
So as was pretty much stated in my original post I am interested in OpenHab because it has reversed engineered protocol access to proprietary devices. In the first instance, radiator valves.
Things descended into a philosophical debate and, as was bound to happen people started to try and sell me OpenHab. Understandable, but I don’t think that is going to happen for various reasons.
I don’t really mind if mine is better or worse than OpenHab ,it’s not a competition, it’s just mine and it does what I need and only what I need.
So maybe, as suggested I will install open hab and have a play around with it and then create a new thread specifically about radiator valves and work from there.
Core OpenHAB does not come with a lot of “stuff” but flexible “menu items” giving you the freedom to choose & customize. If you cannot find your “beans on toast” they provide the kitchen resource framework and tools for you to make your own.
I am on the same journey as you!
I built my own system from scratch. Based on Beaglebone Black, with all the code written in C. Arduino nano in the room thermostats with colour graphic LCD and touch panels. Talking RS232 to an auduino mega that converted it to my own UDP ethernet protocol.
It all worked. It had a web interface. I wrote my own Android app to make the phone interface slick.
The big problem was that expanding it with new features was a complete pain. When I designed it, I hadn’t thought about some of the stuff I wanted to add.
Then I moved to OpenHAB. The learning curve is painful. You feel completely out of control. The documentation is never quite what you need. The error messages are cryptic or non existant. But if you persevere, it all begins to make sense. You begin to realise that the team that put it all together really understand home automation. You can start with a very basic systems and just keep adding the bits you want.
I discovered MQTT - brilliant protocol for what I want. I now run openHAB on Rasp Pi. I converted all my room thermostats to use ESP8266 and talk MQTT. Added a lighting controller also using ESP8266 and MQTT. I do use Google home to control stuff but I don’t use the cloud connector. I just expose specific URLs through my firewall using a reverse proxy. IFTTT with Webhooks to access those URLs. Google can only tell how many times they turn on my lights!
I also run a collection of Sonoff switched hacked to run Tasmoto which also talk MQTT; and a few Tuya switches which are directly controlled by OpenHAB via Tuya API (no cloud). I use mains voltage wax ball value acutators with the Sonoff switches for radiators (as you suggest!)
The beaglebone is still in there but now a slave to OpenHAB and talking MQTT.
Overall I think OpenHab provides a robust extensible framework that allows you to keep adding stuff. You get to spend your time coding the interesting add-on bits.
So I had an interesting realisation. The setup I have for heating may not be ideal for things like lights.
However, some would see this as a failure, but I don’t. I tells me I did a good job of designing a home heating automation and makes me even more resistive to “be all and end all” solutions. Why?
Because controlling lights and controlling heating are two completely different things with completely different design criteria. So if you want one system to do both you will either need a system that support both mechanics or using a glue or adaptor implementation do adapt one mechanic to the other.
For me heating control is about demands. These are stateful, polled, expirable artefacts. They have single sided state machines and always fail safe to OFF. They present easy ways to override demands for time periods etc.
For me lighting is more about events and if they can’t be avoided state machines. I hate state machines. With over 20 years experience in software development any time someone suggests a state machine I insist on exploring any alternative solution first. State machines always seem simple until you run into problems with them. Adding to them multiplies the complexity and they suffer massively from race conditions and competition.
As I understand it, OpenHab is based on Events and State machines. So while that might work for lights, it’s not the correct approach for heating. In the purest engineering sense.
Now, you “can” do a polled demand based system on top of an Event based state machine, of course. You can also flip that around and implement an Event, state machine based system with a polled demand system, but hybrids are not “optimal” solutions and have draw backs.
I think you guys maybe think I sat down and hacked something out and if you look at my GitLab project and dig around you might believe the sometimes scrappy quality of the code confirms this. I have been designing this system for years. Spending hours working through scenarios, what ifs, failure modes etc. It is not a quick hack by any means and it’s not surprising it works well for heating and might not work well for lights, because it was designed for heating and not for lights.
Once more, I don’t understand the point of your post
ANY dynamic system including heating is based on events and state machines. The latter you might be aware of or not as it can be hidden in variables/item states, but it’s there and you can always represent the system in a notation to use state machines (doesn’t always make sense, but you could in the purest sense of computer sciences).
What do you mean to be a “demand based system” ?
A demand to change is an event to occur (or in an extended form to be triggered based on an event plus state data conditions) so how does it differ from event driven ones ?
And demands aren’t static anymore. While not as erratic as with lighting, modern heating (to take presence detection, weather conditions, shading and ventilation states etc into account) is also a lot less static than they have been for years due to limited capabilities in heating controllers (essentially to heat during the day and shutoff at night).
The temperature of a room is not an Event it’s a state. You can model it as a events if you want, but, why would you do that? It’s a waste of time. If you have condition that does something at a set temperature, you could implement an “onChange” Event for the temperature and only pass it to the condition when it occurs, but that’s absolutely pointless unless the Condition is heavy, intensive or has non idempotent considerations.
Events are transient, they mark a moment something occurred or changed. The mark transitions, moments that occur and are past. If something remains static, no event is fired (unless you want to create a NotChanged() event). If the Event that said the room temperature changed from 20.0 to 19.9 *C is lost or the component you wanted to receive it was offline the event is lost and will not be reissued.
Then the event for DropsBelow will only be fired once as the room temp passes 20 on the way down. If that is missed because the component attached to it is offline, it will not be fired again and whatever you wanted to happen when it dropped below 20 will never happen unless it rises above 20 and drops below again.
This is absolutely NOT fail safe in terms of heating and creates, no matter what way you choose to implement it race conditions and fragility.
If whatever is receiving these events is offline when the “Turn Heating OFF” event fires, then the heating will remain on. The state machine will believe the heating is off and your heating runs, possibility for ever.
Yes, yes, yes, I know you can implement fail safes on top of this, great. But why would you do this? Why not start with a polled based demand state systems in the first place that naturally and inherently fails safe and avoids the problem of missed events, race conditions and transactions in the first place.
In my system I implement “isBelow” as a condition and it is checked every time the polling runs and it will demand the heating every time it is below 20. So on a cold evening it might raise 100s of heating demands, most of which are superflous as the heating is already demanded, but if it stops raising a demand either because the temp went above 20 or someone poured a bucket of water over the Raspberry PI, the heating will switch itself off as the demand expires in 5 minutes.
Poor programming, not inherent problem. A more sensible definition would be Temperature has changed and is now below 20
You do realise that there are no steady states at all in your existing programming? Each is a sample from an ADC that converts peridically; each data sample is polled by some other bit of hardware, maybe put into a data packet, sent peridically etc. And that doesn’t matter because your program only looks at it once in a while anyway.
Yes. This comes down to programming abstractions. It all ends up as bits and instructions in a CPU and memory anyway. This true of any computer software. So why bother with abstractions and models at all? That line of argument is fruitless. You write software to support other software and in doing so you create abstractions.
This discussion is around Events versus States. Push versus pull. Message versus polling. They have pros and cons for different requirements. In my view polling demand states is a better fit for a fail safe, robust way to control things for which there is no “realtime” responsiveness requirement.
As to whether or not you think my design is correct, I don’t really care. All I am saying it that I believe it is correct and that implementing it over an event bases system would be tedious and unnecessary.
To use OpenHAB I would consider my heating system a “device” with a “binding” and allow OpenHab to update target temps etc. Just like, maybe, openHab integrating with Nest or EvoHome or similar.
You still seem not to understand well enough what openHAB is. It’s not that converter or library you want to use it for. It’s the heart of the automation. It’s where the control program will run - on openHAB. It’s not meant to run on your gateway or devices (yes I understand that you don’t want it to be like that and that to swallow that is the hard part. I really do). It’s where all the (relevant) states are kept and the logic is executed. And it’s event driven no matter if you like that or not. It is for good reason because it’s meant to integrate different technologies. With your approach it’s gonna get difficult if you want to integrate some other tech or device with your heating such as say a location service that you would want to interact with your system such as person X is now leaving work → start heating her room to have it comfortable right when (s)he is to arrive home.
I already integrate with things such as location awareness, weather station data
To do as you suggest all I need is something that can tell me “she” is leaving work. If that’s geo-fence on her phone and her phone can make a rest request (such as from Tasker) that “state” is published to my “bulletin board” and the particular heating schedule that is interested will see it and act on it. It would work in exactly the same way as my Presence awareness work.
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
59
To throw my hat into this bear pit…
As a great man once said, “don’t make openHAB2 THE thermostat, let openHAB2 control a thermostat” (or words to that effect).
Personally, I have no idea why you would want to risk your home insurance company NOT paying out on any ‘accidental’ damage that may occur in your home, due to a simple bug in some home brewed software.
Whereas, if your simple Target Temperature command to a professional thermostat caused that thermostat to cause a problem, you would at least (assuming it was installed correctly) give you recourse to that manufacturer’s liability insurance.
Which for reference, even I have to have legal insurance to cover my advice, let alone anything I sell to an installer, who in turn has to have insurance to cover their actions.
So in short, why are you reinventing the wheel?
And for further information, everything you are trying to do (with your heating, including multiple sources of HVAC) can easily be done with Velbus hardware.
That is the dumbest thing I ever heard and the main problem with the “Home automation” eco system.
To many half baked, non-interoperatable, proprietary systems, black box systems labeled as “Smart” when in fact they are nothing but dumb remote controls with a fluffy layer of marketing piled on top and usually the only thing separating them from Spy ware is a privacy policy opening admitting to spying on you.
If my system were to cause a fault in my heating system that then caused damage to my home and the Insurance company asks, “Was this system installed by a professional” the answer is yes.
