Hi Folks

Hi guys/gals,

I’m Paul, software engineer from the UK. I have been writing my own home automation system for a few years, slowly. I thought I would come over here and see what OpenHab was about.

My system is probably 20% about automating my home and 80% about the challenge of doing it well, from scratch, 100% DIYOW and mostly 0% about making a reusable smart home system for a market. I think the later is the biggest burner of time on software projects; ie. making it work for everyone, making it idiot proof, making it look pretty, documenting it. So I choose not to do any of those things.

Anyway, OpenHab. The thing that has attracted me to OH is that it has integrations I like. Notably integrations with radiator valves.

I have no radiator control valves presently. I have been rummaging around on the web trying to find rad valves with “close to bare metal” access and coming up pretty much empty, except for mains operated electrical actuator valves with a SOnOff switch which is currently my best option.

But my blinkered “clean room” approach to designing my system has started to crack and I have started to consider adding bridges between my systems’s world and other systems. It opens the horizons into prebuilt commercial systems as “part” of my overall system, rather than have to figure out and source parts to build one myself. I still don’t like having Big Data and Big Privacy Policy that intimately in my house, so no Google, Alexa for me, nope, not unless they can be considerable tamed.

My options are to “pilfer” from OpenHab and re-implement some of the integrations it has figured out while of course trying to find a way to provide something in return.

Or to create an integration module for OpenHab to bridge it to my current system. My system tells OpenHab things it’s needs to know, OpenHab tells mine things it needs to know. Surely MQTT would work there for most things.

I could even be sold on OpenHab as the core system and spend my effort developing with it’s framework. I just need to find time to take interest in the documentation and code and see if I like the eco-system.

If you want details of my system, ask away, but it’s really just a basic presence aware mutli-zone heating and lighting demand and control set up in Python running on a PI with about a dozen ESP8266s and hacked SOnOff modules with Cacti as the only current front end besides shell and REST requests with bare JSON.

1 Like


Here are some of my opinions. OpenHAB is Java based but much more focused on stability than the Python-based Home Assistant project.
I believe there are Z-Wvae based radiator valves available. Z-Wave lets you maintain local control without an Internet dependency. @chris our Z-Wave developer is very dedicated here as are many others.
I cannot advise much on radiator valves since they are not too common here in North America.

Thanks, I had heard about Z-Wave before, probably through google and here, but life got in the way or something. I’ll have a new look. I think I might have frowned at it being an overly complex binary protocol? “How difficult is turning on/off a switch or reading a value? Seriously.”

Still using it as a bridge to other devices like rad values in an option.

Are there many other “semi-open” protocols that work local only that might bridge to ?


I personally frown on Wi-Fi & Zigbee because vendors only use the crowded 2.4GHz RF space even though both standards have other options.
On Linux I have a USB Z-Wave controller that communicates with OpenHAB fine.
@chris is our detail expert on ZWave in his spare time. At work, he is a space systems engineer. A smary guy that is really dedicated/

ZigBee does not currently support use of any other bands. There are some moves afoot to change that - 868MHz was recently included to support UK SmartMeters that don’t work so well on 2.4GHz, but that’s only available in Europe, and only for SEP, and not home automation.

Sorry I was thinking of IEEE 802.15.4 on which Zigbee is based.

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.:cry:

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.


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.


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 :wink: ) 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.