I suppose one approach might be to have access to some kind of “poll complete” flag, which is only set after the binding has updated OH Items with register values read from Modbus. And presumably unset before commencing a read poll. A property of each Bridge poller?
Seems clonky though. With correct configuration, all registers will get read in a single Modbus transfer. The only asynchronous part is where the binding updates related OH Items one by one. I reckon a simple delay of a couple of milliseconds would allow that to complete (after triggering a rule from any Item update).
Alternatively, figure out which will be the last Item to get updated in each poll, and trigger the rule that demands synchronizing off of that Item?
I think if the binding’s update behaviour is predictable, we already have the tools to ensure a block of data is synchronized.
(@jotpehenn I would appreaciate this feature, let me know if there is news, I can serve as guinea pig if you need one.
(@rossko57 Alternatively, figure out which will be the last Item to get updated in each poll, and trigger the rule that demands synchronizing off of that Item?
I think if the binding’s update behaviour is predictable, we already have the tools to ensure a block of data is synchronized.
I checked the code – the current order is “arbitrary”/unspecified but probably the same every poll. Not sure if the order would be different over time (when openHAB is rebooted). In other words, it’s all error-prone implementation details…
Following from @rossko57 clunky idea, I guess it would be easier if the poller would have the the lastReadSuccess and lastReadError as channels. You could then use these to process the data. However, you would have to assume that data would not be changed in the meanwhile while you are iterating over the individual pieces of data.
Will think about this…
For now I’m not proceeding with implementation, would like to get the pull request through, and then introduce incremental improvements and new features. So don’t hold your breath…
(@jotpehenn … then use universalwrite.js to “dynamically” generate the JSON to basically write anything anywhere in any quantity, i.e the data thing is not bound to a specific address, data type or how many registers are written in one go.
There are some more advanced use cases which need more control how the command is converted to set of bits or requests. Due to this reason, one can return a special JSON output from the transformation (step 3). The JSON directly specifies the write requests to send to Modbus slave.
You should even specify the writeMultipleEvenWithSingleRegisterOrCoil since the transform output specifies the exact function code that will be used.
Ah, knocks that plan down. I presume this (binding updating multiple Items) is a fairly rapid process though, happening before/while update events are put on the bus? A short delay at the beginning of a rule triggered from an Item update should surely allow ‘associated’ Items to all settle down.
There may be other benefits in having those poller properties available, dunno what they might be yet. A user needing synchronised data is going to have to manage polling carefully, to ensure processing completes in between polls.
Hi, I have avr device with modbus implementing by MBS38. It works fine. it works with mbpoll and openHAB ver2.3.0 market bindings - PAPER UI.
but I try to use .items . things .sitemap files. with using this files my data are unavalaible - in BASIC UI. Can anybody look at this files? is there any mistake?
thanx Martin
file .things
//poller thing -lenght, type are required
Bridge modbus:serial:endpointMOXA[port=“COM7”,baud=9600,id=11,dataBits=8,
parity=“none”,stopBits=“1”,encoding=“rtu”] {
Bridge poller holdingsREG[ start=0, length=6, refresh=2000, type=“holding”] {
Thing data temp1 [ readStart=“0”, readValueType=“int16” ]
Thing data temp2 [ readStart=“1”, readValueType=“int16” ]
Thing data temp3 [ readStart=“2”, readValueType=“int16” ]
Thing data temp4 [ readStart=“3”, readValueType=“int16” ]
Thing data temp5 [ readStart=“4”, readValueType=“int16” ]
Thing data temp6 [ readStart=“5”, readValueType=“int16” ]
}
}
file .items
//itemtype itemname “labeltext [stateformat]” //<iconname{channel=“modbus:data:nameOfBridge:nameOfPoller:nameOfVariable:number”
Number S1 “Temperature [%d]” {channel=“modbus:data:endpointMOXA:holdingsREG:temp1:number”}
Number S2 “Temperature [%d]” {channel=“modbus:data:endpointMOXA:holdingsREG:temp2:number”}
Number S3 “Temperature [%d]” {channel=“modbus:data:endpointMOXA:holdingsREG:temp3:number”}
Number S4 “Temperature [%d]” {channel=“modbus:data:endpointMOXA:holdingsREG:temp4:number”}
Number S5 “Temperature [%d]” {channel=“modbus:data:endpointMOXA:holdingsREG:temp5:number”}
Number S6 “Temperature [%d]” {channel=“modbus:data:endpointMOXA:holdingsREG:temp6:number”}
file .sitemap
sitemap default label=“My house” {
Frame label=“Temperatures” {
//Text item=datum
Text item=vychodS
Text item=zapadS
Text item=S1 label=“Sensor1[%d °C]” icon=“temperature”
Text item=S2 label=“Sensor2[%d °C]” icon=“temperature”
Text item=S3 label=“Sensor3[%d °C]” icon=“temperature”
Text item=S4 label=“Sensor4[%d °C]” icon=“temperature”
Text item=S5 label=“Sensor5[%d °C]” icon=“temperature”
Text item=S6 label=“Sensor6[%d °C]” icon=“temperature”
}
in Classic UI it works too, in HABmin - there are 2 sitemaps : my house - it is from BASIC no data from modbus, in home - configured in PAPER UI - all data are relevant
Thanx for your reply. I wrote , all things are green online. thank you for your job in this, martin. if you mention what I have to send, please tell me. May be it is any basic, elemntary thing , Which I do not know. Last items and things are corrected as your last document at github
I can see the data as well for temp1, temp2, etc. in one of the screenshots. For example, temp5 is 268.
Perhaps there is some format error with S1 etc. labels? Try to remove the labels from sitemap, that is, having the following default.sitemap:
sitemap default label="My house" {
Frame label="Temperatures" {
//Text item=datum
Text item=vychodS
Text item=zapadS
Text item=S1 icon="temperature"
Text item=S2 icon="temperature"
Text item=S3 icon="temperature"
Text item=S4 icon="temperature"
Text item=S5 icon="temperature"
Text item=S6 icon="temperature"
}
}
Right. I’m afraid I don’t know what is the issue…it does sound like something basic with the sitemap & items.
I recommend posting a new thread, to Items & Sitemaps section. Since you can see the data (the second picture you posted here), the problem should not be in the binding.
it is solved.
the problem was en-coding of notepad++. default was ANSI. and in my PC was UTF-8 BOM.
I have to convert encoding for .items file - now works
thanx Martin
I can’t get the TCP slave or polling service to work with your binding. I have installed both the transport bundle and the binding. I have stopped the Modbus 1.12.0 binding.
I create a TCP slave thing, and insert my modbus gw IP:port, and this is my error message:
2018-03-31 07:27:48.322 [WARN ] [ore.thing.internal.ThingRegistryImpl] - Cannot create thing. No binding found that supports creating a thing of type 'modbus:tcp'.
So I’ve uninstalled the old binding and restarted OH2, and here is the log:
==> /var/log/openhab2/openhab.log <==
2018-03-31 19:05:11.250 [INFO ] [core.karaf.internal.FeatureInstaller] - Uninstalled 'openhab-binding-modbus1'
==> /var/log/openhab2/events.log <==
2018-03-31 19:05:11.257 [thome.event.ExtensionEvent] - Extension 'binding-modbus1' has been uninstalled.
==> /var/log/openhab2/openhab.log <==
2018-03-31 19:05:16.342 [INFO ] [b.core.service.AbstractActiveService] - Modbus Polling Service has been shut down
2018-03-31 19:09:36.486 [INFO ] [rt.modbus.internal.ModbusManagerImpl] - Modbus manager activated
2018-03-31 19:09:36.782 [INFO ] [modbus.internal.ModbusHandlerFactory] - Setting manager: org.openhab.io.transport.modbus.internal.ModbusManagerImpl@182182f
2018-03-31 19:09:37.082 [hingStatusInfoChangedEvent] - 'modbus:tcp:7c70c957' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_REGISTERING_ERROR): org.eclipse.smarthome.core.thing.internal.ThingImpl cannot be cast to org.eclipse.smarthome.core.thing.Bridge
2018-03-31 19:09:37.081 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occurred while calling thing handler factory 'org.openhab.binding.modbus.internal.ModbusHandlerFactory@1d06784': org.eclipse.smarthome.core.thing.internal.ThingImpl cannot be cast to org.eclipse.smarthome.core.thing.Bridge
at org.openhab.binding.modbus.internal.ModbusHandlerFactory.createHandler(ModbusHandlerFactory.java:66) ~[?:?]
2018-03-31 19:09:37.377 [hingStatusInfoChangedEvent] - 'modbus:poller:791bca5f' changed from UNINITIALIZED to UNINITIALIZED (BRIDGE_UNINITIALIZED)
I tried to update the thing in Paper UI:
2018-03-31 19:11:59.253 [ERROR] [st.core.internal.thing.ThingResource] - Exception during HTTP PUT request for update config at 'things/modbus:tcp:7c70c957/config'
java.lang.IllegalStateException: Thing with UID modbus:tcp:7c70c957 has no handler attached.
Thanks for your time and help.
After several rounds of deleteing and recreating of things, I now got my slaves up and running
Seems like the old binding also caused some issues when installed and stopped. So uninstalling as suggested was a good idea.
The binding work great now, and I have to congratulate you with a great job on this binding. Thanks!
I’m starting a project for my smart home with openhab2. I want to avoid wireless systems and use a wired network. I choose the RS485 Modbus. I will connect some arduinos on the modbus with sensors and switches.
I’m trying now to start with a simple example just for testing purposes of swithing a LED on the arduino throught a modbus connection between the arduino and the Raspberry Pi with Openhab2.
I have this material:
Raspberry Pi with Openhab2 (raspbian);
USB-to-RS485 FT232 FTDI Adapter (to connect the Raspberry pi to Modbus); IMG
MAX485 RS-485-TTL Module (to connect arduino to Modbus); IMG
I would appreaciate this feature, let me know if there is news, I can serve as guinea pig if you need one.
