I thought I would document my first steps with OpenHab, just in case somebody finds it useful.
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
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.
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.
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.
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!
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.
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.