I’m trying to get my openHAB to work with Carlo Gavazzi Dupline controller. I can’t get openHAB to write to controller.
To me it seem that the problem is that when I use coil or holding type, it first tries to read from the coil or register, but controller does not allow to read from those addresses, just write. Therefore all the modbus binding is doing is looping through error and restart and can’t get to writing. And even if it could, it would be ugly, binding trying to read all the time, processing error and just occasionally writing.
On top of that, CG controller does allow read/write to single coil/register for majority of functions. So I can’t bind modbus to the whole range of addresses and then use xxx:<a:>b syntax.
Anybody experienced similar situation, when read and write coil/register addresses are not the same for reading and writing? Any idea how to address this problem?
To me it seem that the problem is that when I use coil or holding type, it first tries to read from the coil or register
The reading does happen with the poll interval. If the controller does not allow reading, you will surely get errors. As far as I know, this should not prevent normal write commands to go through.
What version of the binding you are using? Please try again with 1.9.0 snapshot version.
On top of that, CG controller does allow read/write to single coil/register for majority of functions. So I can’t bind modbus to the whole range of addresses and then use xxx:b syntax.
This seems to be the case for many people. You can workaround the controller limitation by defining many “slaves” in openhab with same end point but different address. The “slaves”
Anybody experienced similar situation, when read and write coil/register addresses are not the same for reading and writing? Any idea how to address this problem?
Read and write can be different. Please consult the wiki for details how to configure the item. But yeah, the binding will still read the registers etc you have defined in the configuration.
The idea looks quite ugly. I was going to poll Dupline controller at default 200ms to keep openHAB updated, but writing would happen just a few times per day. Meaning modbus binding would make 3 tries per read with error and reset serial each time, there would be more tha a million errorneous events per day just to have a few writes…
Anyway, I’ll try this at least to see how does it work.
I’m on 1.8.3 on Ubuntu 16.04. I haven’t been following openHAB versions closely, isn’t 1.9.0 still in development? I googled a bit and didn’t see a clear way to upgrade from 1.8.3 to 1.9.0. Should it work if I just copy modbus 1.9.0 version binding into /usr/share/openhab/addons ?
According to what you say it should be writing anyway, but for me it does not happen. The polling events of two “slaves” I have defined does appear in the debug log, but I don’t see any writing events (I tried 5th and 6th modbus functions). How does binding work: should writing event happen at next modbus poll after the item value is changed or should I expect specific write event?
The next candidate after upgrading is to recheck items and sitemap, it might be I didn’t got syntax right.
Yes it’s still in development but still I would highly recommend it since the 1.8.3 contains so many critical bugs, especially with serial slaves. With 1.9.0 at least the serial line is not reseted, not sure about 1.8.3. You also have much more control with the retries etc. I would not expect too much slow down if the controller responds instantly…
I understand the workaround is ugly but unfortunately I can’t think of any other immediate workaround for your case.
I think what you would need is to ability disable / enable polling per each slave. This should be quite straight forward to implement…
I rechecked my code before going into upgrade to 1.9.0 and that was the main problem, it works now
Plus, I got lucky with one of the write functions on one range of the addresses, those are readable too. Reading noise, but at least there is no error. So, very good for further testing/exploring, there will be no need to dig through logs full of error messages.
And the answer to my own question: write events are separate modbus events, these doesn’t happen during polling cycle.
So, I’ll not go into upgrade at the moment, I will explore current possibilities first.
Yes, you are right, disable/enable polling would solve my issue when polling non-readable addresses. I might still need this, because I’m almost sure there will be Dupline controller address range / write function combinations where address will not be readable.
Thank you for following this thread, it really helps when you can talk to somebody!
Please note if you are working with multiple physical serial slaves, you need to update to 1.9.0. Furthermore, with modbus RTU the binding did not wait enough between different transactions which lead to failed requests (as rtu the silence is part of the protocol).
You might be interested to know that the reading noise is also fixed in 1.9.0: if the value remains same, no state update event is submitted to openhab event bus (by default). This has been reported to reduce cpu load significantly with short poll periods.
I’m happy to help if you have issues with the new version.
I am also working with modbus to CG controller since a couple of weeks, type SH2WEB24… What CG controller do you use?
I had some problems as well at first until I understood the structure of adding slaves for each request.
I am using 1.9.0 SNAPSHOT with good results, at least for digital I/O and temperature readings so far.
I added more than 1000 slaves to modbus binding, Each slave with its individual startadress and lenght of 1 or 2 depending on type. It seems to work without any other tweaking of polling time etc.
Noted about several physical slaves. At the moment I have just one modbus slave, CG Dupline controller, but who knows. I noticed the RTU silence issue while reading documentation, but I haven’t hit that issue so far myself.
Yeah, seem that 1.9.0 is a way to go for me. At least because, although openhab.log is clean of errors so far, events.log is full of redundant read events even though value does’t change much. So updateunchangeditems parameter is definitely useful.
Do you know if openHAB 2 has further improvements in terms of interfacing modbus slaves?
My CG controller is type G 3800 0015. I installed it ~9 years ago. Actually, I’m slowly turning off Dupline channels, because I’m moving my smarthouse in other direction now, MySensors project as an example. But I’m by no means planning to get rid of CG yet. Therefore I’m interested in any experiences and ready to share mine. Especially because there is not a lot info available about CG products, seem that those are not popular with enthusiasts / smarthouse communities according to what I have found out.
I’m not planning to define every CG modbus address as openHAB slave. I really hope it will not come to that. So far I’m polling the state of the whole controller by means of one slave and I have defined 8 more slaves for writing short pulses to any Dupline channel. Meaning, I’m doing and going to do bit operations in openHAB. Works fine. Except that I need to upgrade to 1.9.0 because with 1.8.3 events.log is full of items updates records while item does not change often. My next plan is to define 8 more slaves for switching any Dupline channel permanently (as if transmitter is turned on the cannel). My Dupline channels are grouped depending on what type of operation is intended for them: I manage lights with pulses, then there are outlets/devices being on/off more or less permanently, some are just status channels. Meaning I probably won’t need as much as 17 slaves I counted so far.
I haven’t started to work on dimmers. Actually, it is hard for me to imagine how to manage CG dimmers with openHAB well. CG dimmers can’t accept arbitrary light levels afaik, only preprogrammed ones. From the other hand, openHAB is being managed by mobile app in my case and that app is not responsive enough for realtime manual operation of the CG dimmer. My thinking there goes as fas as configuring some preset scenes or replacing CG dimmers with something more modern.
Plus, I have an idea of building physical MySensors controls for control of some CG dimmers. I have made a prototype with touch sensors, openHAB is able to get state of those pretty much realtime, but I lacked modbus part so far. Some work ahead on that idea.
So, I’m open for ideas regarding CG dimmers.
And not just dimmers. One more thing in my pipeline is to push daylight sensor data (or just status) to CG, because I managed to burn my CG daylight sensor and I’m not willing to buy new CG one.
There are more ideas, but important thing for me is to get some experiences now. Let’s keep in touch.
I know this one very well too. If you have any questions regarding Dupline modules or controllers I can help you out, I have worked with tech support on the system for many years.
However, I am a total newbie to openhab, and i find it very interesting to try to make automation between systems. I have a complete installation with CG-products so automation of lights, tempzones, alarm and anything else that CG Smart-house can do today (with SH2WEB) is done autonomously.
My goal is to connect sonos, smart-TV, weather, bluetooth etc to CG smart-house with the help of openhab, to include also other smart-things in automation. For example, when turning on TV to a movie channel, i’d like openhab to pick this up and activate a Movie-scenario on Dupline to set all lights and curtains the right way.
This is true with the dimmers you have. They work as a “push-dimmer”, but also with preset scene-levels and feedback if on or off.
The dimmers I have, SH2D500W1230 is possible to control both with scenarios and 10-100% from modbus. This is what I referred to, the Dimmer-item and slider does not do what I want so far…
I think it is possible to use some bindings as a astronomical timer, maybe could be used?
My CG controls lights, including few scenarios and automation, some power outlets, get’s state from (external) security system, does couple of rudimentary operations to heating and air management. It’s a pity there was no way to get practical support when I started with CG, from the local seller or community. I might drop you a question or two, I’m just thinking it is not the topic for this forum.
I’ve been using openHAB for a bit more than a year, reading from and controlling ~ 20 objects in my home. And yeah, integrations are one of the main areas I’m thinking of and working on. I’m pretty happy with what openHAB offers. As I said, the heart of my smarthouse is not CG controller anymore, it’s openHAB
Ok, if you can write dimming % to modbus, I’d suggest you not to try to directly bind openHAB dimmer/slide to CG dimmer via modbus, but separate those objects and do the sync in the openHAB rules. This approach has worked for me for a couple of cases already when integrating two systems which doesn’t match 100% or doesn’t do it easy way. E.g. I have MySensors controlled dimmable christmas lights around the house, a few dimmable Milight lights in the house and I have found it easier to manage when I do not bind directly to openHAB slide. Maybe because of my (very outdated) SW developer background
I’m mainly thinking of managing the lights from the openHAB now, not doing any daylight level involving logic in the CG. As a backup plan: writing analink values to CG.
Playing around with modbus binding, it seem that it is not stable. When I restart openhab, it does not always come on normally, to be more precise, it does not connect to slave. I have to do restart openhab several times when I need a restart, until modbus starts normally. I tried to stop/start just modbus bundle in osgi console, that does not seem to help (or I was just unlucky). Maybe I have to restart serial too in such cases?
But I think I have to go for upgrade to 1.9.0. I googled a bit and did not find answers to the questions:
Will it work if I copy just modbus binding version 1.9.0 to /usr/share/openhab/addons directory?
Adding more modbus slaves (of the same CG controller) I noticed that it’s more and more hard to get openhab stable regarding modbus communication. Untill I did add 5th slave and was not able to get modbus running at all anymore. Removed, works again. Seem that some kind of overload happens on initiation / first poll. Need to debug further.
Finally got some time to get into it. Turned debug on and activated the next modbus slave, cg8 is the ID in the log. Not every time, but more often than not I’m getting errors. See ~1.5 minutes of the openhab.log after restart here.
Of this behaviour you might be right that modbus slave can’t handle it and I need to play with connection parameters.
But. What can be observed on the log extract above is not the worst case scenario. In that case it is not just slave cg8 which can’t be polled, none of slaves can. I just don’t have more time today to reproduce the worst case.
In the worst case around the time of the restart this happens in system log (dmesg):
[775278.958669] ttyUSB0: 1 input overrun(s)
Please note that modbus slave is on ttyUSB1, not ttyUSB0. On ttyUSB0 there is serial interface to Arduino based gateway for communication with MySensors devices.
I have no proof, but my feeling is that it is not modbus slave which can’t handle the speed then, it’s openhab which can’t handle something.
I hope I’ll get more time to dig deeper on weekend. Meanwhile, your advice would be appreciated.
OK thanks for the log, it was really useful. The error you have is EOF returned by the serial library when reading the response: http://pastebin.com/LHkbaP3n
I can see that you have configured the system correctly in the sense that all openhab “slaves” (cgX) share the same serial connection (there is only single “pool configuration”, i.e. /dev/ttyUSB1 endpoint):
Could you please provide modbus configuration from the openhab.cfg as well as the item definitions? We can tune the connection parameters and try that one next. Other than that I do not have any other leads yet.
What I can say that we have had really good and stable serial performance out of the modbus binding on linux (with 1.9.0), and I’m hoping we can make your setup work as well.
Good to see we have some Smart-House users. I am approved installer for CG in the UK. I have had CTRLZ and SH2 controllers working with Openhab for some time now. I am controlling lights and blinds using Amazon Echo via Openhab. All good stuff. Willing to share experiences. I am too now trying to get dimming and temperature setting working via Openhab. Did you manage to resolve the dimming issue?
