Of course, this is fine when you are building a DIY system. If you were to use standards (eg ZWave, ZigBee…) then the standards take care of that. The ZigBee binding for example should work with any device that provide specific features - there’s nothing to add.
Standards provide a lot of interoperability, and using a common standard such as ZWave or Zigbee provides a log of options for devices. If you do your own system, then of course there’s no need to worry about this.
Maybe - maybe not. All these devices are REQUIRED by law to inter operate and not interfere with other systems, but also to be able to accept interference from other systems. I work with a large hotel chain that has WiFi and uses ZigBee for their room control - everything works fine in what is a very dense environment.
True, but then we’re back to the original requirements - a mesh network will provide you this as well. If you just have one or two devices in your house, then sure, use 433MHz. If you have more devices, then using a system with a mesh network actually provides better penetration and increased robustness.
Really? The abstracted core model with things and a couple of item types is pretty lean, and any user just needs to add those bindings to the game that cover his device technologies.
So it`s up to everybody himself how complex that gets. If you minimize the number of technologies and maximize the number of devices per tech chosen, you minimize the amount of work (which you need to spend per tech but not per device) but this does not change the complexity.
ZWave is a good example: it only gets a very little bit more complicated than it is today when there’s a new version, and that isn’t all that much more complex (unless some great new functionality is introduced but that does not happen).
Point is, that’s adding complexity per-tech not per-device. It doesn’t make a difference to complexity if the ZWave binding supports 10,100 or 1000 different devices as it does today.
Yes someone has to be the first to add a new ZWave device to the database but this is another great advantage of Open Source Software: it’s not you as the software creator or maintainer who has to do that but the users themselves do so. Everybody gets ‘his’ devices to work and shares this with the community so even you can then also run that device. Which is clearly desired when you approach the same problem with the user’s will in mind (not just the implementer’s) as it is giving options to you (and to anybody who is not as capable of solving his needs as are you).
Let alone the same thing to happen on binding layer - you already own a more or less exotic HVAC device that you want to become part of your smarthome ? Media integration ? Your lawn mower robot ? Any fancy cheap new device like Shellys or any from the full range of established standards that openHAB supports (ZWave, KNX, ZigBee, EnOcean … all relevant ones, essentially) ? Someone from your country or the far end of the world owns it, too, and already has developed the binding so you can start using it.
And yet you are running on a general-purpose CPU with a general purpose, but modular OS (assuming Linux) using a general purpose language named Java.
OpenHAB is similarly modular. The core openHAB does not support much of anything without installing a binding. Even if you follow the official tutorial, you need to install the Network binding to detect devices on your network.
Z-Wave Plus is designed for long battery life without vendor lock-in to their product. The binding is developed by a European space engineer who has great attention to detail.
You are also free to write your own bespoke bindings to work with the OpenHAB core, giving you the benefit of the expertise of this volunteer community.
So OpenHAB as an integration layer for me, is an option.
However looking briefly, and I do mean briefly. The core does not seem like something I would adapt to. It’s architecture doesn’t seem to be the way I want to go and would be a step backwards for me.
Maybe I’m being unfair, but let me what I have and how I would achieve that in OpenHAB.
Decoupling between state, events, demands and actions. A schedule in my system might raise a demand for heating in the living room because it’s temperatue is below target for the given time and conditions. I don’t currently have a way to heat the living room independently, but the schedule does not need to know or care that I do or don’t. All it knows is the living room needs heating, it doesn’t care how or even if I deliver that, so it simply asks for that demand and it’s job is done.
A separate mechanism processes demands to determine what action can or should be taken and raises a much more specific demand for an action to be carried out, such as “turn the heating on” or it could choose to ignore it. This demand processor does not need to know how such a demand for heating is served and doesn’t care, it just decides the main heating should be on.
Another component again sees the demand for heating and specifically commands the end device to switch it’s relay.
At all points in that chain the data and demands have expiry times. If I log in now and kill the heating controller service, the demand processor or the scheduler the heating will still switch itself off when the demand expires. (Some of this is not quite implemented yet). It’s designed to be fault tolerant with many points of failure and scenarios checked to have fail safe outcomes (bugs aside) and still provide manual intervention at all points where practical. I can still turn my heating on or off manually.
Most (though not currently all) of these components are not only separate processes but are not required to be singular or on any particular host. With the exceptions of the data hub where data and demands re published which has a fixed IP that has regrettably been flashed into about a dozen different EPROMs by now.
Asides fault tolerance and distribution of services this layering approach provides me with places to encapsulate how things are done and provide separation of responsibility. The heating scheduler nor heating controller need to know that my boiler has no “anti short cycle” and so that must be provided by my relay control. So it is provided at the relay control, close to the specific device that requires it. If I am controlling an electric fire with an IR sender there is no requirement for anti-short cycle but the heating controller doesn’t need to know that either.
(as an aside… anti-short-cycle is not a fancy cool feature, it is an absolute safety requirement, if I have a software bug which results in the heating being toggled on, off, on, off repeatedly every few seconds the boiler will flood itself with fuel which could in very real terms end up with a fire in the boiler when it does finally get ignited and then the garage… and potentially the house).
If a schedule wants heat in the living room, it doesn’t need to know how I deliver that, it could be the main boiler, it could be opening (or closing) the curtains, it could be sending an ON signal to the electric wall fire and turning an aircon unit onto heat. So the heating schedule is agnostic of “how” I provide heat.
The heating controller component similarly does not need to know the specifics of how I command an electric fire to be ON via an IR signal, it just tells that device to be ON. Nor does it need to know why the heating was or was not requested. Additionally the heating controller can make decisions around “appropriate use”. If for example heating for a specific room has been demanded ON for the past 4 hours the heating controller can refuse to keep it on and switch it off as it’s been on too long, something is probably wrong.
So what each layer needs to take care of it takes care of and encapsulates that away from other components needing to know. While this creates what is seemingly a complex archecture, the individual components are very simple and with shared trust that they each take care of their own responsibilities they work easily together.
OpenHAB seems much more Event based with state machine logic and direct coupling of Events to actions. There is limited flexibility. Now maybe using chains of virtual items and so on I could maybe achieve this demand based system, but… this is exactly what I mean by “Burden of complexity”. If the OpenHAB conventions and architecture does not inherently support what I want to do I end up having cludge and hack my way around it’s complexity to deliver what I want… or start modifying it’s core and that’s a bigger/deeper rabbit hole.
I want to add that I’m not saying OpenHab is doing anything wrong. It’s just that as I started from a clean sheet and mostly maintained a “clean room” approach to how “I” would control heating I came up with a different way of doing things and currently anyway I like that approach.
It seems that you do not want a “central server” approach, and indeed OH is intended for that approach. Beyond one or two, OH would be ridiculously over the top for a distributed service (though it is possible).
And what would the “demand” be? I assume one Event, via a Rule can raise another Event? And can one Event be serviced by multiple rules? This is the only way I could see to create the chain of responsbility.
Of course I suppose I could hang the demand service off OpenHab and use rules to publish and poll it.
Don’t get me wrong, my archtecture is not perfect either. I am a little jealous of Event based stuff as my demand based system is done with polling, so while I can manually create a 1 hour demand by holding the button the heating switch due to the poll interval on the heating controlling being 30 seconds, the heating might not come on for 30 seconds.
The interval on the lighting controller is 1 second, for responsiveness to buttons, but that creates quite a lot of network noise.
Well, it’s just a logic concept. One way to represent it would be to hold it as an Item state, if you intend to process it further with OH.
Other (multiple) rules can act when this state changes to “demand”,or stops being demand come to that. One might tweak an independent thermostat target,one might close the curtains and send you a text about it.
Another rule can come along at midnight, and do this or that depending on demand still being active.
Or you might just post the event to some service as a message, if OH has no further interest in it.
In your current process I presume this “demand” is a state resident in some box that other boxes must poll and consider for action. There’s always more than one way to skin a cat.
I’ve gone to quite a bit of trouble to have wallswitches that act as directly as possible on lights. Makes a good user experience. OH “listens” to these happenings and knows what is going on. OH also handles “left on for hours” timeouts and “motion detected lights-on” where a bit of latency in server or network is irrelevant. Bonus of course, that it is livable if OH or network blows up.
But that’s about selecting the technology at the endpoint, not the automation mechanism.
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).
