My first steps with OpenHab

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