Hi Sami,
thanks for the code example! It looks like it shouldn’t be too hard to switch to the Modbus binding instead of the external library I currently use.
At the moment I can’t really sacrifice much time to continue with the migration to OH2. But once I have an OH2 version up and running a switch to the Modbus binding would be a good next step.
Thanks again & best regards,
Bernhard
Great! If you like and you think it would make sense, I can extend the api to have synchronous methods as well, compared to current async methods with callbacks.
On the other hand, with async api, you would probably get the most performance as there are no blocking calls anywhere.
Let me know if you want to improve something in the api.
I experienced a strange behaviour of the binding.
Once i set the mode to manual and changed the fan speed, the KWL works in the correct manual mode, but the item is set back to automatic. Can anybody confirm this?
Hi, i forked your repo and did an update a few seconds ago. I only added some code to get the external libraties running on OH2. I only add some code to get the date from the helios but currently i am not able to get the value. I got an exception while setting the register to read.
I just want to get the current code running before change the Modbus libraries and so one, but currently it does not work and i currently have no idea. Maybe one of the developers who know something about the modbus connection is able to sind me a tip why the connectino currently fails.
This version is miles away from a version who is able to use for a normal user. But i just want to give you an update and send a alive message. I also have a runnig system meanwhile so i am able to test the code.
Here is my location:
Cheers
I found the error i missed the setUnit command with the offset of 180. Now the communication is working on my local environment. I will now try to use the openHab internal lib to communicate with modbus. After get this running i will implement all the values which are able to load via modbus. After that i will do an commit and it will be free for public testing.
cheers
Hey, did you notice the discussion related to modbus transport bundle I have been working on. You can find the pull request here.
The transport bundle is made exactly for cases like this, to support development of protocols and devices that are based on modbus protocol. I am also working on plain modbus binding for openhab2 (using the transport bundle) but it’s quite clear that it’s not suitable for Helios . See above posts for some motivation and crude example of using the ModbusManager from modbus transport.
I am happy to help if you need support, I think it should be pretty similar to using low level modbus library like jamod, but with more safety features (correct handling of serial modbus, ensuring single connection at a time to a particular slave) and features (e.g. retry).
Best
Sami
P.s. Not sure exact details of Helios but you might be able to reuse quite much stuff from the binding as well. With modbus binding there are two things, one for the endpoint (ip/port or serial and some connection settings), one for the data (instructions how to convert value to in modbus to number or value in openhab and vice versa)
Thank you very much. Now i am able to read all the values with the current implementation. I have seen pull request, next step will be change the code in that way. Now i have a running impmenentation and now it will be easier to find an error.
Cheers
Hi
I have been thinking how the Helios use case would look like with the API in reality.
Helios has some specialties that might need some work on the binding side, especially the fact that one “Helios transaction” consists of many modbus requests (e.g. write followed by read). Say you have two transactions, both consisting of write followed by read: write1-read1 & write2-read2. We probably want to ensure the nice order (write1 -> read1 -> write2 -> read2) instead of mixed order (write1 -> write2 -> read1 -> read2). The safest in this case would be to “synchronize transactions” on the binding side.
In the below example (implemented as unit test), Striped from Guava library is used to “lock” the endpoint for single transaction at once. Note that the ModbusSlaveEndpoint interface provided by the modbus transport guarantees that equals and hashing is implemented correctly as required by Striped.
In case you want to abort ongoing requests, you can fire off a thread and interrupt it (see below how interruption has been handled).
I have been experimenting with CompletableFuture as well but I think it might be overengineering and the below code is actually pretty readable.
import com.google.common.util.concurrent.Striped;
// locks for "Helios transactions"
Striped<Lock> locks = Striped.lazyWeakLock(5);
@Test
public void test() throws InterruptedException {
Manager modbusManager = new Manager();
ModbusTCPSlaveEndpoint endpoint = new ModbusTCPSlaveEndpoint("localhost", 55502);
Lock endpointLock = locks.get(endpoint);
try {
endpointLock.lock();
// submit first
{
final AtomicBoolean success = new AtomicBoolean();
final CountDownLatch completed = new CountDownLatch(1);
WriteTask write = new WriteTaskImpl(endpoint,
new ModbusWriteRegisterRequestBlueprintImpl(0, 0, new ModbusRegisterArrayImpl(2), true, 15),
new ModbusWriteCallback() {
@Override
public void onWriteResponse(ModbusWriteRequestBlueprint request, ModbusResponse response) {
completed.countDown();
success.set(Boolean.TRUE);
}
@Override
public void onError(ModbusWriteRequestBlueprint request, Exception error) {
completed.countDown();
success.set(Boolean.FALSE);
}
});
ScheduledFuture<?> writeFuture = modbusManager.submitOneTimeWrite(write);
try {
completed.await();
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
writeFuture.cancel(true);
throw e;
}
if (!Boolean.TRUE.equals(success)) {
// failure, abort?
// TODO: log
return;
}
}
// submit second
{
final AtomicBoolean success = new AtomicBoolean();
final CountDownLatch completed = new CountDownLatch(1);
// Proceed with next query
}
} finally {
endpointLock.unlock();
}
}
Do you think something like this would work for you?
Btw, please note that helios-based-on-modbus2-transport is already obsolete. The latest Modbus binding and transport code can be found from modbus-openhab2-native-binding branch. I suggest you build Helios binding on top of that branch, using the transport bundle. Prepare to rebase your changes on top of my changes if necessary.
Please note that the new transport contains the implementations for requests, previously my example included implementation for WriteTask. Check all the public implementations and interfaces from source code: java/org/openhab/io/transport/modbus.
Finally, should you post a “WIP” PR (see here for motivation) to Github?
Best,
Sami
I wanted to thank you for your efforts. - I have an Helios KWL EC 200 Pro with an RS485 interface, how do I find out whether it is also the modbus you are mentioning? It would be great to have this integrated into my virgin openhab installation.
If it helps I can offer some testing…
@bern77 and @ssalonen what is the status with your work? Is the modbus transport stable and usable? Is there some progress about the helios binding on top of that?
Hi @ramack,
sorry for not getting back to you after the last post. The RS485 interface is a different physical interface than the Modbus/TCP interface used in the binding discussed here. While the protocol implementation might be reusable, the current implementation (at least mine) wouldn’t support RS385 as the transportation layer I’m afraid.
But your KWL containing “EC” in the name should suggest there is the Modbus/TCP option available… I think “EC” stands for Easy Control which should be the web interface to control the KWL. At least in my case this means that the Modbus protocol is also available via the TCP connection… in this case I think the binding implementations should work.
Hi!
I think the transport is stable in the sense that there have been many positive experiences from the community.
I think the code can be considered stable, no large changes recently…
The pull request is still pending merge, waiting time for the maintainers to review the code. No ETA on that.
When it comes to Helios, my recent post shows one way for the implementation, and suggestions for going forward. However, that’s all from my side, not planning to develop anything for Helios specifically. Naturally if changes are needed from modbus transport, I am very willing to help!
Best
Sami
Ah thanks for the clarification. I now understand, that I would need the Modbus/TCP interface for your binding. - Probably I am not willing to buy that. I would prefer to have a binding directly connecting to the RS485 interface used by the remote control.
@ssalonen Thanks for the update. Anyhow, @bern77’s answer shows, that it is actually not too interesting for me. Sorry for the noise.
I just stumbled across the following:
https://www.npmjs.com/package/helios2mqtt (Based on Modbus TCP)
Using the OH MQTT binding this might be a fairly easy way to integrate a Helios KWL with OH…
I have to come back with one more question:
@ssalonen did I see it correct, that the modbus transport should also support serial RS485 physical layer?
@bern77 In that case a change to the modbus transport of your helios binding would be automagically support Modbus RTU, wouldn’t it?
Yes, the transport supports serial devices
Sami
@ramack I think so, yes.
However, I’ve not yet really progressed the upgrade to OH 2.0 for the Helios binding. To be honest, since so many OH bindings are still based on the 1.x architecture I don’t exactly feel an urge to move forward with this.
Maybe the implementation of @big_blue is some steps ahead here?
Hallo
gibt es schon eine Lösung dafür ß
habe das gleiche Problem
Dirk
Hello,
I am trying to install the Helios KWL binding some time ago. unfortunately, without success. I just can not get the binding installed.
I pushed the jar file into addons. Ip set up in the cfg. But how do I install the Jar file? or is it enough if it is there? what did i forget? or is not the binding with openHAB 2? I would be happy for any answer.