Yes, but ZigBee itself doesn’t support these channels. Any system could use a different frequency, but one of the nice things about ZigBee, and the 2.4GHz band in general, is that it’s global. This is a major ballache with ZWave unfortunately.
As a Wi-Fi guy I deal too much with interference & cheap 2.4 GHz Wi-Fi devices to depend on 2.4GHz.
For Wi-Fi I only have 1 channel interference-free at home thanks to the neighbour’s “expert” who set their system up on channel 7, interfering with both 6 & 11.
Just curious, what’s that “SEP” (I assume it isn’t the infamous “Somebody Else’s Problem” reality distortion field from the Hitchhiker’s Guide, is it ?)
1 Like
It’s the ZigBee “Smart Energy Profile” - used by SmartMeter systems around the world.
1 Like
I would offer this suggestion. If you like openhab and have the skills to contribute. Go ahead and use openhab as your core and give back to the openhab community by writing integrations that everyone could use.
3 Likes
Paul: Welcome to the OpenHAB community!
easily doable in OpenHAB
more stuff that is super OpenHAB friendly… no problems
OpenHAB could run as your foundation and leverage your current system or run in tandem with it
If python is your language of choice check out Sebastian’s HABApp
1 Like
Or, without adding another daemon, you can use Jython but it is Python 2 based.
Obviously we would like you to use openHAB as your core; you are on an openHAB forum after all. MQTT would be the natural protocol to bridge between your system and openHAB (or any other home automation platform). MQTT has kind of become the protocol to use in home automation if you are using DIY, and even some commercial devices have got in on the act and support MQTT out of the box.
openHAB can easily become wholly self contained. There is no requirement for any cloud services and you are not required to use integrations with any other company like Amazon or Google. But of course this also means there will be many products and capabilities that will be off limits for use.
For wireless, Zwave, Zigbee, and RF 433MHz seem to be the most common alternatives to Wifi. Zwave has excellent support and compatibility but they tend to be a bit more expensive. Zigbee can be cheaper but there are a bunch of devices that “extend” the protocol creating special cases and other complications. RF433MHz tends to be one way only so there’s no feedback.
It’s a wireless protocol that operates in a self forming mesh network and supports hundreds of different types of devices. How simple do you think it can be? If just reading a sensor or flipping a relay were the only requirements that be one thing. But, as far as I can tell, that is the least of the requirements.
But one advantage of using a framework like openHAB is I don’t have to care. Developers and experts like Chris figure out this complex stuff and I can use it without needing to care about how any given message is bit packed or routed through the self forming mesh network. That’s what APIs are for.
Anyway, since you are comfortable in Python, it might even be possible to move some or all of your current code to run on openHAB itself through JSR223 Rules. By default openHAB provides a Rules DSL which most programmers find limiting. It is definitely inflexible in many ways. But OH also supports writing rules in Jython, JavaScript, or Groovy.
1 Like
Hi @paulcam Welcome to OH. There are several options for using Python in OH. You can do scripting using Jython (Python 2.7). Or use HABapp. Or link your work and OH over MQTT. Many options (which can be confusing). I have done a fair bit of work with presence/occupancy in Jython if you are interested. OH has a great community and I have found the system to be extremely stable. Mike
Thanks for the replies. … and apologies for the rant below…
tldr; I don’t like complex, generic, adaptable, jack of all trade, highly extensible systems. I don’t like big companies controlling me and spying on me.
It’s interesting, but I keep coming into design ethos conflicts with systems like OpenHAB (and many others) these days. It’s not really a matter of me saying I do not agree with OpenHAB (or others) approaches, but it is a matter of “design for purpose”.
I am in a unique position. I can design and develop what I need. So I can’t fairly attack these kind of systems which are used by people who can’t. But, in the context of what I want to achieve I feel like I will attack them. Attack in terms of frowning and grimacing at the complexity and bloat they suffer from. I will say this having not, yet, browsed the OpenHAB code, so it’s possibly unfair to point that finger at OpenHab.
If you want to create a system that works for every kind of device and works for every persons requirements and home, a system that is easy to use, idiot proof, pretty, well documented, support umpteen languages and locales, then yes it will be complex, yes it will bloat, yes it will be large, expensive and slow.
I don’t need any of that. The comment about Z-Wave being a complex mesh network that works with hundreds of different devices is an example. I don’t want nor need a mesh network. I don’t need nor want to work with hundreds of different devices. Why would I need a protocol that can work with a WhizzyDuffer2.0 when I don’t have, nor will ever have a WhizzyDuffer2.0? Why would I want to burden my system protocols with the intricacies and complexities of controlling a WhizzyDuffer2.0 when I don’t need to?
When you remove all these superfluous requirements you would be absolutely amazed at how simple these things actually become.
Extending this out to my day job (Senior Java Engineer in Big Data for Capital Markets and investment banking), I am currently tasked with removing and replacing a complicated system that someone decided to create as an all bells and whistles, can do everything and anything related to ETL (Extract Transform Load) of data, which turned into a massively over-engineered, highly abstract, generic, completely infuriating to work with monster that nobody wanted to develop in. It was slow, resource intensive and basically failed to deliver performance on non-commodity blade hardware with 100s of cores and 100s of GB of RAM. It’s being binned. The system being put in place is designed to handle the requirements bestowed upon it and ONLY the requirements bestowed upon it. Anyone in a design meeting who says, “But what if we have a different type of a thing later”, gets told to justify that in context of the CURRENT requirements or is silenced. Anyone who creates an abstract class gets asked to remove it unless they can absolutely justify it for the requirements as they stand NOW, not some fantasy prediction of future reality. In software, predicting requirements and creating highly extensible applications does NOT work anymore. Software life cycles in enterprise and much shorter today with systems being replaced in 5-10 years, not 20-30 years. Requirements change far too fast, you will never predict them all and when that one requirement you didn’t predict turns your framework upside down you have a much larger mess to fix, usually resulting in more layers or complexity and more angry developers, over budget, over time, unsatisfied clients.
In context of home automation each and every company is seemingly trying to create their own bespoke system. They are typically be-all-to-all systems, jack of all trades, master of none, which is understandable though infuriating. However they suffer badly from corporate spite and greed, boxing in, refusing to be compatible with their competitors. Standard procedure in the domestic computing market and not just the domestic. I have hopes that as “smart” home stuff becomes more and more popular that interopable frameworks and protocols will gain more and more traction, things like MQTT are a start. Things like IFTTT are NOT. However with Google, Amazon and Apple hitting it hard it is also likely that traction for open protocols will wane and those big three will become the defacto standards.
I realise there are developer APIs for those big three and that would open up the eco-system of either accessing those devices via Google/Amazon offering or making my devices support their protocols, but Google/Amazon come with the privacy policy issues. I use facebook, I use GMail, I use Amazon prime, but I am not oblivious to what I am providing them with and it’s risks to my privacy. Using Alexa or home assistant however is one step too close into my home life and many bits of data about me too far for me to have these in my home. That could change in the future, but for now, it’s a no. I urge the users of said devices to read the small print and really think about the data they provide, not just in how it is used today and by whom, but how that data could be used by someone you DONT want to have that data and for what? We already have the police, local councils, employers, insurance companies all demanding access to peoples Facebook and Amazon Alexa and Google devices and not just current access, but historical access. Something you did or said in your own home 2 years ago could come back to bite you later because “Google Knows”.
There is light glimpsing through the tunnel with MQTT. But MQTT does not define the payload and it’s highly likely when devices supporting MQTT for use with Google/Amazon start to be more common the payload will be locked down to ensure it can ONLY be used via Google/Amazon and enforce remote cloud based MQTT brokers, just like IFTTT forces cloud services.
It’s not just the privacy issue, it’s the control and ownership issue. These third-party protocols are subject to change, end-user-license agreements and each and EVERY one of them pretty much says, “The license issuer reserves the right to change, remove, disable or block any and all uses of the service, including disabling devices.” You DO NOT own any of the system, you are just licensed to use it at Amazon/Google’s whim. What this means is that in 5 years time the feature of Amazon Alexa you were using to run half your home can be simply switched off. In fact, Amazon/Google reserve the right to permanently brick your devices without asking permission first. This has happened already many times, devices and services switched off or deleted remotely without your consent, because you consent is not required. Nor does it matter how much you paid for the device or use of the services you have to read the small print!
I’m probably preaching to the choir here on this, but I think where I could come in conflict with OpenHAB will be it’s complexity in it’s attempt to support all devices in all homes for all people. I only want to support my devices in my home for me. You can call that selfish, but I will happily provide people with code and help to do the same. It’s more about ownership and control of my home and it’s technology, because I am in a position to do so.
Obviously I have conflicting issues here. I want full control, but devices out there that I might want to use do not want me to have control over them without using their services. OpenHab has the ability in some cases to circumvent that control back to me. So it has appeal, just not yet sure if I’m willing to accept the burden of that.
Maybe I should take some time this weekend and download OpenHAB and see what it can do for me and browser the code to see if (a) I can borrow code and (b) provide code in return. (I do get how OpenSource works).
If you read this far, thanks for for your attention and appolgies if I upset or offended you. Please don’t flame me too hard.
Paul
1 Like
On a different technological note.
RF and Wifi. I have found that 2.4Ghz Wifi is fine for me. I have a TP-Link Acher AC9000 router and even in the garage I can get enough signal to send and receive data enough for home automation. Granted installing a security camera which output an uncompressed HD image and sound might present a challenge, but if I’m honest, security cameras should be wired with off site recording storage or they are effectively a paper cannon.
For systems for which I need good solid high speed bandwidth I hard wire them with CAT5e or CAT6. I am not a speed hound, GigaEthernet is fine!
RF. The appeal I have for 433Mhz RF is the power saving advantage. There are requirements I have for things where running a 5V or 12V power supply is not feasible and there are, like in light switches, no neutral wires available. RF light switches exist that are only powered on when the button is pressed. the 10-20ms you press the switch for, powers the device and transmitter long enough to repeatedly send it’s signal. Thus batteries in these kind of switches can last for years, if you are lucky.
Conversely a Wifi based switch will consume 20-50mA constantly to stay on the Wifi and send/receive data. Trying to use the switch to power such devices would require you hold the switch for a few seconds to allow the Wifi to connect, so battery operation is not really feasible.
I have looked at SOnOff RF switches and their RF bridge, but I’m not convinced yet. Most people seem to be installing Tosmota or ESPurna which I want to avoid presently. Just need to find lower level documentation on how to take control of their RF bridge and maybe I can get it to work.
There is no big company controlling OpenHAB. In fact there is a nonprofit foundation that owns the product specifically to avoid that.
Possibly not, but what this gives you is the ability to buy the devices that YOU need. If you buy a system that only has 2 devices, it’s probably perfect if those are exactly the devices you want. However, when you (or your partner) find you want to do something else (as always happens 
) then you have nowhere to go. Investing in a system that has the option of thousands of devices means you are more likely to find a device that meets your needs…
Mesh networks - I agree - absolutely no-one needs a mesh network. What people need is a system that provides a wide reach (ie a good range). The mesh network is something that provides this - there are other ways (higher power RF for example). You should focus on the requirements you want in the SYSTEM and ignore the IMPLEMENTATION. People here tend to be more interested in the implementation as it’s a hobby oriented system, so people (understandably) like to know how things work, but it shouldn’t be the overall focus.
I’m not sure what 433MHz brings to this. Typically a 433MHz system is more power hungry that a SIMILAR 2.4GHz system. I don’t include WiFi here, but I DO include ZigBee. It sounds like ZigBee Green Power is exactly what you are looking for (it’s an energy harvesting system). Unfortunately at the moment it’s still being rolled out but it is mandatory for any new ZB3.0 systems so is worth a look.
I get that. My fear about OpenHab is accepting the burden of complexity for features or compatibility I don’t need. That and being effective forced into conventions and hopping through hoops within the OH eco-system.
I’d be more inclined to just add support for devices as I need them. Specifically I currently have two controllers. Heating and Lighting. But as I control the end devices, can do basic electronics and can write firmware I made the end devices as complicated as they needed to be for my purposes, which means actually really simple. The Heating controller is currently almost redundant as all it does it poll for demands and switch the heating relay… but it provides a layer to do other things like control the heating loop temp for example. It’s about 20 lines of Python.
Yes there is more to switching heating than just a boolean ON/OFF, but as I could implement to my own specific requirements the code was fairly simple. For example the heating switch (A SOnOff inline switch in series with the heating 7 day timer) has features such as, manual ON/OFF push button, remote control via HTTP, anti-short cycle (it will reject attempts to toggle it too fast) and integration with the demand and data systems. A “long press” on the button raises a demand for 1 hour for the opposite state of the relay. If it’s ON and I press for 2 seconds it will raise a demand for 1 hour OFF state overriding the automatics. it publishes it’s state to the data hub “Bulletin board style data blob” It also supports OTA programming. Yet the firmware code for this is still only about 250 lines of C++ and took me 1 afternoon to write. If I could get that kind of low level access to all devices I want to use it would be great, the problem is, very often you just can’t.
I will (and do) happily provide this code to anyone who wants it. You would need to be a bit clued up on flashing SOOnOff devices and the demand and data publishing systems might need tweaking to work with something like OpenHab (I don’t even know if OpenHab works that way).
Sorry I just meant when compared to Wifi. I think using RF on 2.4Ghz is a little foolish these days with Wifi (and bluetooth) so agressively using that band. I know it’s a nice open consumer band, but still. 433Mhz will have better range and penetration too, that’s just physics.
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.
PS: what’s the point of your post ?
1 Like
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.
2 Likes
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.
I would agree
No idea why you think that. OH rules fit in here.
No idea why you think that.
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).
2 Likes