My first steps with OpenHab

Tags: #<Tag:0x00007f5c98b5da28>

I thought I would document my first steps with OpenHab, just in case somebody finds it useful.

1 Like

The hardware

After consulting with the experts here, I bought a Raspberry Pi 3B+, an RFXCOM RFXTRX433E transmitter/receiver for my Somfy blinds and awnings, an 8GB micro SD card, an Smraza casa for the RPi, an official power supply to get the full 5V and a USB 300 Enocean gateway. I already had a Gen5 Z-Wave stick.

I first removed the thermal pads that came on the three heatsinks provided with the RPi case, cleaned the chips with alcohol pads and substituted Gelid pads that I had left over from redoing the thermal pads on my Alienware. That was pretty fiddly. I noticed a potential problem: one of the chips is on the bottom and the Gelid pads are less adhesive than the standard pads, and gravity may do its work and pull the heatsink off the chip over time. In fact, it fell off shortly after I put it on. I pressed it back on and so far it still seems to be in place. I’ll keep an eye on it. It may need to be held in place with thermal tape - which I also have left over from my laptop job. Putting the case together was easy. It also comes with a fan, which I connected on low speed. It’s completely silent. Heatsinks plus a fan may sound like overkill, but it seems that a fan is what really makes the heatsinks effective. And heat is the enemy of all electronics.

To connect the RPi to my router I needed to borrow a cable from the desktop PC. I have 4 ports on the router and a 4-port switch (7 ports in total), and they’re all full. Ultimately the Zipabox will be disconnected, so that will free up a port.

The basic setup

I downloaded the Openhabian SD card image and Etcher. I wrote the image to the card. I turned on the RPi and stuck the card in, and went away to do some stuff. I’d read it could take as long as 3 hours (this later appeared to be a huge overestimate). Then I realised that at some point the switch had been turned off and may have interrupted the setup (which needs a network connection). I redid it from scratch. Then I tried to connect to http://openhabianpi:8080 and got nothing. I tried to connect via SSH using PuTTY, reached the login, tried the defaults pi and raspberry and got “access denied”. Had I tried “openhabian/openhabian” at this point, I would have been fine, but I didn’t know that. This is where I went slightly off the rails. I looked up the “access denied” problem and somebody said you needed to activate ssh by include the file “ssh” in the root of the boot image. I redid the image and found, of course, that the file was already there. I then discovered the openhabian login/password and connected successfully from PuTTY. Now I reasoned that it would be a good idea to make the IP of the RPi static - forgetting that there is a DNS name you can use. This caused me all kinds of problems. With a static IP, I couldn’t see the RPi at all. Not sure why. I finally got rid of the static IP, connected with the DNS name and all was well.

Installing my first bindings

I got into Openhabian config and installed Mosquitto and maybe something else, I forget. I was able to access the web interface and chose the standard setup. I entered Paper UI and installed a few bindings - Nest, Tado, Modbus, OpenWeatherMap, Z-Wave, etc. I successfully added the Tado (I guessed that Tado Home meant the Tado thermostat) and got the “things” in the inbox for hot water and the thermostat.

Adding my Brink heat-recovery ventilation system (Modbus)

I added a Modbus bridge for the Brink ventilation system - connected via an adapter which converts Modbus RTU to Modbus TCP/IP - and that appeared to connect successfully. I tried adding some data entries for pressure, temperature, setting the control mode and so on, but got “offline - configuration error”. That could be down to any number of things. The holding register addresses I wasn’t sure about: it said to start from 0, but I’m not sure how that corresponds to the numbers in the Modbus documentation I have for the Brink. I know from the Zipabox that I needed to subtract 1 from the documented numbers because it doesn’t apply an offset. I interpreted the “zero-based” reference to mean that. But elsewhere I’ve seen it stated that the “first register should be 0”. I’m not sure how that would apply to the Modbus addresses I have, which start at 4002, continue intermittently until 4060 (read-only holding registers - function code 0x03), and then continue from 6001 to 6013 (write holding registers - function code 0x06). Oh and there’s also address 1000, also a write holding register, for setting the slave address). For now I’m working from the assumption that I need to use the documented register address minus one.

The things could be offline because I haven’t written the value 4 to Set Control Mode to switch control over to Modbus from the control panel. No idea at the moment.

The Modbus register address/numbering issue is as old as time. But three quarters of the battle is knowing it exists, which you do :smiley:
Just try reading for expected values (like your reg 1000) to find out in any given case.

Most likely means what it says, a config problem as opposed to a communication problem. Looking in openhab.log may give you more clues.
We can help, with more detail. If you want to keep this thread clean, by all means start a new Modbus specific one.

2 Likes

OK but I think you have to subtract one, right? That’s what I’ve picked up from other posts.

Yes, I’ll try to just make this a journal of my first steps with OpenHab. If I need to do a deep dive into the Modbus issue I’ll do a separate thread. This thread isn’t really intended to ask for help (although help is welcome). I haven’t really gone into the problem in depth myself yet.

If you don’t already have a Works With Nest developer account with an app already registered you won’t be able to do anything with this binding. And even if you do you will probably only be able to use it until the end of the year. Google is discontinuing the API and replacing it with one that it won’t give third parties like OH access to the data. I just want to save you some time and trouble.

Thanks for posting. Threads like this are very helpful.

1 Like

It’s been a long time since I’ve added to this thread, but I’ve finally got around to messing with OpenHab again.
I have taken a few baby steps. I’ve worked out what things and items are. I’ve managed to get a Modbus poller online - but I’m not sure how yet.

I took a scattergun approach by adding several pollers for different address ranges. From the beginning I was confused by the message next to the address field: “Input as zero-based index number, e.g. in place of 400001 (first holding register), use the address 0”. I still don’t know what that means. Thanks to a post by Berndq I was able to ignore this and use the addresses I had from the Brink Connect documentation - minus one, of course. What I’ve observed is that periodic restarting seems to help (another post also suggested this). Modbus things that don’t appear to be working suddenly start working after a reboot.
It also appears that the “bridge” for the Modbus data things has to be the relevant poller, not the ventilation unit thing itself. Since I got the impression that you could skip polling altogether, I found this confusing. My first half-success yesterday was getting the “online” green light on a data thing by making its bridge a poller - even though the poller itself still showed a communication error. My next small advance was creating an item to show the value - although it only ever showed NaN.

Today I’ve finally got a full-on positive result. After restarting, my bypass poller is online, and I can now read out the value in an item.

Now I’m going to try to figure out why the other poller isn’t working.

Since I’ve observed that, alarmingly, the Brink’s automatic bypass mode doesn’t seem to be opening the bypass as it should, my near-term objective is to control it with a simple rule based on a couple of temperature readings. That would be further than I got with the Zipabox in five years. :smirk:

Breaking the pollers up was the key to success. For some reason, the last register I was trying to read, exhaust pressure, doesn’t work. The others are fine. Now I need to work out read transformations.

I’m controlling the ventilation flow rate and bypass valve from OpenHab, albeit manually. Feeling pretty happy right now!

2 Likes

I bashed my head against the wall for a long time to get my first read transformation working.

To connect I just used Explorer (technically Directory Opus) with the IP address and deposited my map file in the transform directory. I saw on the forum that it needed to be UTF8. Fixed. The initial contents were:

0=Initialising
1=Opening
2=Closing
3=Open
4=Closed
255=Status unknown

which are the values of the bypass valve position, which is clearly a number. Therefore, my item was a number. But I kept getting “Channel number will not be updated since transformation was unsuccessful. Channel is expecting the following data types [DecimalType, QuantityType, UnDefType]. Input data: number value 3 (value type ‘uint16’ taken into account) and bool value true.” Following examples on the forum, I tried adding:

undefined=unknown
-=No Data
=Blank

But no luck. Then I just simplified radically to:

3

which should cause the value 3 to appear as a blank string, following the documentation. No dice. So I tried creating an item for “Value as string” and that did it. I can guess now why it worked - the item type has to match the output, not the input. That never occurred to me.

The next transformation I added was to divide a number by 10 using a chunk of javascript. I copied an example to get the syntax-voodoo required:

(function(i) 
{
    return parseFloat(i)/10.0;
})(input)

but the result was missing the decimal places. I couldn’t work out how to fix that with a number item, so I just used a string item and took advantage to add the unit:

(function(i) 
{
    var nTemperature = parseFloat(i)/10.0;
    return nTemperature.toFixed(1) + " ºC";
})(input)

I managed to convert the bypass valve control and the control mode into switches, with a transformation to map the values. The values generated by the switch turned out to be ON and OFF (I expected 1 and 0). I learned this from the log. Okey-dokey. So my map for the bypass value looks like this:

OFF=1
ON=2

I’m getting a ton of Modbus communication errors at the moment. Not sure why.

Also, I’ve lost openhabianpi. I have to use the IP to access PaperUI.

I’m now looking into how to move to use configuration files and how that fits/doesn’t fit with PaperUI. Apparently PaperUI uses a database, but it’s possible to manage items in files and things/bindings in PaperUI? This is all rather foggy.

There’s lot to say about Modbus. You’re not talking into the void here, but if you want to get into techy detail it feels like you might want to start another thread, and leave this one as your “experience diary”.

I will throw in a generalism - Modbus setup is a baptism of fire for non-techy folk. It’s an ancient low level protocol - meaning dimwitted. We have to supply the thinking when configuring, which is a very manual process. There is no consistency amongst target device behaviours.
Bottom line is that we have to get down among bits, bytes, and registers for success with Modbus. At heart it is simple, but requires care and background knowledge. At least we can share the last part!

Thanks. Yes, if I feel I need to open another thread I will. Everything still seems to be working, and it may be as simple as a congested network (the Modbus connection goes over IP) due to teleworking. No idea. It did seem to coincide with me connecting to my work VPN. It’s just a “that’s odd, I wonder what’s going on” rather than “HELP ME NOW!!”.

All my reads and writes are now working just fine, apparently, so I think I’ve figured out the registers, bits and bytes.

Hi

This is s great thread you’ve created.

I’ve got a couple of customers with ModBus kit that I’ve managed to steer clear of, having read your thread, I’m glad I have.

I am really pleased to read that you are mastering your setup and getting it to work how you want it to.

As Rich says, these kinds of threads are incredibly useful in all kinds of ways.

So here’s a common bit of confusion.

From what I understand…

The whole setup of openHAB2 Things, Items and their links are stored in JSON files.

Regardless of how the individual parts are created.

  • RestAPI
  • PaperUI
  • Text files
  • And others that access the RestApi

To start with, I restricted myself to PaperUI, because my needs were basic and it seemed to work well.

As I branched out into different bindings and third party connectivity (like Tagging & Metadata for Alexa & Google Assistant) it became clear that PaperUI can’t do everything.

Having read lots of other people’s thoughts and comments (for which I’m very grateful), I’ve adopted the following pattern

Add bindings through PaperUI wherever possible, as dependencies are taken care of there.

Create Bridge Things in a Text file (however I’ve recently learnt that the auto generated Thing ID can be set when created in PaperUi, which makes restoring / moving systems much easier)

Use PaperUI exclusively for adding Things, as getting the channel & trigger syntax right can be troublesome

Create Text file Items, which can be manipulated quite easily.
Adding groups, tags, metadata and secondary links to bindings (for example the amazingly useful Expire binding)

I’ve gone as far as to make one Item file template which has everything I could need, which I copy and trim / edit until I have all the items for a Thing in a corresponding Item file.

This way, I can quickly find and edit the Items.

(“Alt & Click drag” is an amazing editor feature that I discovered on this journey)

These threads show the evolution.

1 Like

Great info.

Yes, if I looked for a ventilation unit again, I would try to get one that uses Z-Wave. Modbus is teeth-grindingly difficult, and a compatibility nightmare. I’m close to the 5th anniversary of trying to get control via Modbus - on the Zipabox it’s still not working and I don’t see any reason to keep trying now that it’s up and running in OpenHab. I’m a programmer, but there’s no reason that Modbus’s function codes, registers and subtracting (or not subtracting) one from them are going to make much more sense to me than anyone else until I’ve become fully immersed in their weirdness.

Good info on PaperUI. So, am I to understand that the “database” is actually a collection of (editable?) JSON files? What would make sense to me is if you could use PaperUI and direct text file editing to manipulate the same configuration files - is that the case? I’ll actually go and hunt around in the file system and see what I can find. It might be the quickest sense to make sense of it.

That’s what it does, when you create or edit Things, channels, Items.

This is of course dangerous and can kill the system. It’s not very convenient, because you must stop system first. Needs must to fix a problem, but not day to day.

1 Like