So maybe I could do what I want, but I think I would have to go about it in a round about way. So I’ll stick with looking into OpenHAB as a secondary component for integrations.
On integrations, one thing that might be useful to you is my presence awareness mechanism.
I googled for hours and each time I had an idea a google search would reveal it had downsides. Another google search would present a different idea and I would test it and find it was naive or had downsides of it’s own.
Specifically I wanted to use my phone (or anyone registered with the system’s phone) connecting to the Wifi as a signal that that phone and therefore person is present.
Pining the phone… nope. The phone doesn’t respond when sleeping.
ARPinging the phone… nope… same thing.
Having the phone ping the hub to publish it’s own presence. Nope. While I could get “Tasker” to fire it’s timer correctly when connected to Wifi once the phone went to sleep Android silently failed to send the network UDP packet.
On a long shot I SNMP Walked the TP-Link router and found the connected devices OID table and experimenting found that my phones MAC and IP appeared within 10 seconds of my phone Wifi coming on and disappeared within 10 seconds of it disconnecting.
This provides a very reliable and responsive way to know if someone is present in the house.
I’m sure this could be wrapped in a binding and would be of use to people with TP-Link routers or possibly other routers if they provide this OID table and the configuration is updated with the correct OID.
For later fun I still have to try ESP32 bluetooth radars for individual room presence detection. I do not expect that will be easy.
It is indeed. Approximately 12 lines of Python code to create both receive and send threads and network sockets.
The advantage of demand state and polling is that nothing gets forgotten or missing “on the wire”. A demand will be processed and reprocessed repeatedly while active. I actually have to implement state machine logic closer to the device if I don’t want it to be constantly actioned over and over.
So if, for example, a demand is raised that ultimately turns the heating on but something else just turned it off 20 seconds ago, the heating switch will reject that with a 400 Bad Request. With an event based system that’s more or less the end of the road, the event performed the action and it failed. But with a polled interval demand based system the demand will be reactioned and the controller will detect the heating is still OFF and send the ON command.
I don’t like state machines, even the ones I have had to do I don’t like as they always create race conditions.
EDIT: Ah, the keyword is: Idempotent. If you try and keep the device idempotent then you can reaction things as often as you want and they will always have the same effect. If you turn the heating on 50 times, it will still only be on.
I don’t think you have well understood what openHAB really IS, what it does and what it does not.
Maybe it helped if you tried running it (something smallish on demo level ) ?
openHAB does not do anything of all that application level stuff you describe.
You must program it first to do that, and you must program ALL of it. There’s no libraries and not even templates (read: you can program it to work the way you want it to.)
It comes with a choice of rules engines (or scripting languages) that are to a greater or lesser extent limited but it does not prescribe which one to use.
OH is not built as a scalable microservice architecture like today’s cloud services which you seem to be looking for but then again, there’s no point in building it like that. It is designed to run on low end HW in your home and nowhere else (no 19" rack in my basement either). You could even build a mesh of openHAB instances to communicate via MQTT or other means, but that sort of is over the top unless for sake of exercising (I just saw that @rossko57 answered along the same lines).
Yes it is event driven in principle, but there’s no actions directly coupled. There’s a fully programmable routine started, that’s what an event triggers. In the most simple point&click rule engine in PaperUI, yes so it seems these would just be simple actions. But no serious user would use that. There’s the rules DSL (did you see that at all? Or is your judgement based only on what you can access in PaperUI ?)
And there’s Python/Jython and JavaScript available. And if all else fails to provide the flexibility you’re looking for you can also hit the ground and do that in Java…
And allow me to re-raise my question you have not answered: what is your point of this whole thread ?
Of course it isn’t ; getting a rejection message is an event. It’s up to you if you want to ring a bell or try again later or ignore it.
You can construct your own events - “sent a message a minute ago, but nothing happened” is perfectly do-able. As is “he’s supposed to contact me every 2 minutes, but 3 minutes have passed”. As is “I will check every minute for condition X and stop doing Y if it has gone” etc.
Because your time has value. Do you want to self code each and every thing custom? Do you want to build up each and every circuit from the ground up? If so then, yes, openHAB is not for you. Nor is pretty much all of the typical home automation protocols, technologies, and capabilities.
And you will forever be severely limited in what you can accomplish because you will never be able to dedicate the millions of man hours that have gone into projects like this.
But here’s the thing. Yes, the Zwave protocol is complex. But from the user’s perspective I tap a button on my computer, press a button on the device and boom, it’s now part of openHAB. From the user’s perspective it’s super easy.
My time has value. I want to spend my time building my home automation. I don’t want to spend my time writing each and every line of code that runs on all of my ESP8266s, building UIs suitable for my family to use, sitting at my desk for hours with a soldering iron building custom hardware, etc. Because I’m able and willing to build upon the work of others I will always be in a position to accomplish more than you ever will be because I can leverage thousands of man hours of other people’s work.
Depends on your perspective. For me, nothing is as simple as adding a new Zwave device to my home automation. Literally every other technology I’ve dealt with is much more complicated for me to include and use in my home automation. If I had to code it myself, then yes, it would be far more complex. But I don’t.
And on this same line, if you remove all those “superflous” requirements, you pretty much exclude anyone one else from being able to accomplish anything with home automation at all unless they are professional or semiprofessional coders with experience in electronics. I’m sorry, I’m not willing to cut off so many users from this hobby in the name of “simplicity.”
I think you may have a fundamental misunderstanding about what a platform like openHAB is. Your digression about your day job is kind of an apple to oranges comparison. Why? Because the developers of openHAB, or really any similar platform isn’t a software program. It’s a software development platform/environment. It has more in common with Java EE than it does with Firefox. It does nothing on it’s own. What it does is provide an environment in which a user can build their own bespoke home automation system. And each and every user has their own requirements for that system. A platform like openHAB is an enabler.
Honestly, none of this is relevant to openHAB. Don’t want to use Alexa or Google Assistant? Don’t use it. openHAB can work with these but openHAB doesn’t work with anything by default. You have to make a positive decision to install and configure an add-on to enable that.
Not quite correct. There is a non-profit that owns the trademark on openHAB. The product is open source and not owned by anyone, at least not in the typical sense.
Some days I try to say something with a thousand words and someone says the same thing in 15 words. This this this!
This doesn’t take into account the cost of your time. Like I said above, to include and start using a new Zwave device takes me literally no more than 10 minutes. It would take me hours over a few days to build a custom device that does the same thing. I’d rather spend my time on the automation of my home and less time on the little stuff that someone else can and has done and did it as good or better than I could.
And also like I said, this DIY approach excludes a huge number, perhaps the majority, of people who might want to create home automation and have the same concerns about privacy and cloud services that you do.
I am not and never will try to convince you that openHAB is something that you should use. I’m certain you will find it too complex and bulky. But it feels like you are telling us that we are doing home automation wrong. I strenuously reject that. openHAB provides a platform that enables non-developers and even some non-technical folks who are willing to learn the ability to build home automation systems that rival anything that commercial outfits can offer.
Honestly, that’s all openHAB really is. It’s an integration layer that provides some abstractions (Things and Items) and “modules” that hang off of that layer to provide capability. These include bindings (interfaces with technologies and APIs), Persistence (saving data to databases), Rules (where the automation occurs), and UIs (administration and presenting an interface for the users of your home).
Based on your description, I would call this “rigidity in approach.” openHAB’s approach is no more complex than the approach you described. But it is different. And it would indeed be a burden to try to force your approach onto openHAB’s approach. Again, I’m firmly of the opinion that openHAB is not for you. But I’m also firmly going to defend that openHAB’s approach is legitimate. It’s only complex in this case because you want it to work the way you want it to and you are not actually assessing it in the way it was designed to work.
This is solved. The Network Binding has a way to use arping to make it work or you can look at iPhone Presence Detection with hping3 and ARP - #28 by rtvb which has a script I’ve been using for years and it works great with iPhones and Android phones. I’ve never had it not report a phone as present when it is in fact present and asleep.
SNMP is another way. Some users run scripts on their routers (DD-WRT usually) and in Europe there is a FritxBox that has bindings for support in OH.
There is already an SNMP binding and some users do in fact use this for phone presence detection.
If you move to RPi 0Ws it’s a solved problem with reelyActive.
Not necessarily. You can absolutely code this sort of behavior in Rules.
If the device is using MQTT, sending a retained message is all that’s needed really.
Not to derail this topic, but wanted to point you to a post I created in regards to SNMP for phone detection.
Currently I am working on helping with the SNMP 2.x binding not working the same way as the 1.x binding.
If you want to throw up any success you have with the TP-Link router on the first link, I’m sure others would enjoy having this as another option rather than trying to get a hold of Cisco equipment just for SNMP purposes.
If so, they would start by fabricating their own components to generate power needed to power their bespoke computer, running their bespoke OS and using their bespoke programming language.
I’m not nearly the technical expert that anyone else in this discussion is. And really, I don’t think the debate is technical…it’s philosophical.
@paulcam, I think you have a lot of preconceived notions of how an automation system should run and how they should be programmed, based on your particular needs and how you’ve developed your system over time. I don’t see anything wrong with that, since you’re clearly capable of doing your own work.
However, you started this conversation by saying:
It sounds like you had some doubts about your approach; enough to warrant research into other solutions, but not enough to conclude that you should shift your paradigm.
If you’re not willing/able to consider changing your mindset, then I’d agree with @rlkoshak that you’ll likely never be satisfied with openHAB. Rather than appreciating what the system can do, you might spend more time being annoyed by what you don’t want it to do. That makes for a terrible hobby, and I wouldn’t wish that upon you.
Personally, I think you are willing to change your mindset, or you wouldn’t be here. But you don’t need to be convinced by us–you need to convince yourself.
So rather than continuing the debate, my suggestion is to install openHAB and get it to emulate your system as much as possible, with the goal of comparing the two. You might find that the trade-offs aren’t nearly as bad as you thought they would be, and that you’re comfortable with the costs/benefits. If so, the paradigm shift is easy.
You might also find yourself wondering why you’re even bothering, or looking for an excuse to stop and do something else. I think that would be a good indicator that you should walk away, because you’re not ready to change your approach to software development. Again, I don’t think there’s anything wrong with that. It’s just who you are at this point in time.
I have a solar panel. I do run one of my own devices from it. I did design, build and solder up my own circuit that runs from it and it publishes the solar panel stats to my home data hub over Wifi. The firmware running on the device was written by me. It is however build from lower level modules and does use the ESP8266/Arduino libraries for Wifi and RS485. As an aside, I have also built my own OS from scratch, from nothing but source code tar.gz files. Following a book called Linux From Scratch. That was my main OS for about 10 years until maintenance became too much of a pain and I switched to Gentoo which allows the same control but automates the dependencies for me. https://imgur.com/OrF77VB
I also built my own headphone amplifier and USB sound card 100% from scratch, including design of the PCB, if you will forgive me for using integrated circuits like the Texas Instrumnets OPA551 op amps and PCM USB interface chips. https://imgur.com/Z6MXMrf https://imgur.com/e54ebij
My mindset change is less of a mindset change and more of seeing OpenHAB as a tool to get access to more devices.
As I stated in my original post, the majority of the appeal to automating things in my home is about writing the software myself. I obviously use code libraries for things in my code, so stepping up a level/layer to use OpenHAB as a component is not that big a step.
Maybe if I install it and work on interfacing it into my existing system I will learn to love it. Maybe not. Maybe I’ll extract and modify the bits I need, providing back any improvements I make and honouring the license.
To that end the main thing that bothers me is that it’s Java. Nothing in Java is lightweight. I still have to find out how much memory needs to be allocated to this. I did scan the install docs, but didn’t spot it. The Raspberry PI I currently run as my hub only has 1Gb of RAM and in my day job the minimum I have seen Java running with is with -Xmx4G and up to -Xmx128G for big stuff. Java is a memory hog for such a small lightweight platform like the PI. But I’ll see what happens. I have been mulling over moving the hub to an actual server anyway. So maybe I’ll install OH on that, they are on the same subnet as the rest of the stuff (for now).
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.
