If the messages of the switches are not recognized correctly or only sometimes, this is probably because the STM is faster and answers/stops the messages before the binding has recognized them.
At the moment I have no idea where the error in the binding could occur. It would be possible that this behavior is also due to the parallel working STM and the messages between it and the modules are recognized incorrectly.
Maybe I could say something more, if you would send me the log of such a situation, with loglevel DEBUG. But I can’t promise it.
thank you for the PHC binding. I’m stuck with an old unsupported PHC STM920 and I happy to discover that a solution exists.
I want to try you integration with openhab but i’m not an expert in electronic. Can you share the cabling for the RJ12 connector and the RS485 adaptor.
The cabling options are described in the README of the new version, which isn’t yet merged.
When using the PHC power supply you can simply connect the wires to its A+, B- connectors and use a standard RJ12 cable to connect it to the modules.
It also makes sense to use the new version as it is much more reliable. You can install it directly in the PaperUI from Eclipse Marketplace or copy the jar from there to the addons folder.
For this you have to install the serial bundle manually:
Run feature:install openhab-transport-serial in the oh console.
I’m not sure to understand. to install the last version, do you mean, go in paperui, in the add-ons left bar, select bindings, seach for PHC in the list and click on install?
Until my pull request is merged the new version is not available there in the normal way. But you can install addons from the Eclipse marketplace, where the new version is available, as described here.
So you have to install openhab-transport-serial in the console with the command above and then the PHC Binding version from the marketplace, what should appear in the binding list in PaperUI.
Information about the tested hardware can also be found in the Readme.
RS485 adapters with an FTDI chip works good for me, e.g. from Digitus or QC Robot.
I had driver problems on the arm architecture like Raspberry Pi, with that the serial communication wasn’t reliable. Therefore I use an Up Board, on which a x64 Linux runs.
But I don’t know if it would work currently on a Raspi or similar, because I tested it for about three years with an older version
The PR with my latest version is merged and included in release 2.5.5. So since then you can install it normally via the Paper UI and use the official documentation instead of the linked readme above.
I would like to switch an existing PEHA system from the PHC controller to openhab. After I disconnect the PHC controller and connect a laptop with ubuntu 20.04 and Digitus DA-70157 adapter to the PEHA power supply input part, I can reliable switch outputs on AM module with address 0 (940/16 AM). However, I cannot switch the outputs on other AM modules with other addresses (940/4 AM). I also tried the adapter Sentronics USB-RS485 but that did not work at all. The AM module with address 0 is connected to power supply output. The AM modules with other addresses are connected after the module with address 0.
What is the correct way to connect the adapter?
Just connect A+ and B- to one of the PEHA modules, e.g., with cables about 1m long?
Should I also connect ground?
Should I add a 120 Ohm resistor between A+ and B- at the adapter? I already tried with 122 Ohm (or 118 Ohm, not sure), but that did not help.
If the 940/16 AM wors with the DIGITUS adapter, all should be right.
That sounds good, even slightly longer cables should not be a problem.
No, you don’t have to.
With the Digitus adapter it works for me without a resistor.
I only have 940/16 AM modules so I couldn’t test it with 940/4 AM modules.
You could try connecting the 940/16 AM with a different address to rule out that this is the reason.
Then you could just connect a 940/4 AM and look into the debug or trace log or send it to me.
You can change the log level in the oh console with log:set TRACE org.openhab.binding.phc.
In the beginning, during initialization many messages are sent back and forth until it is recognized correctly. This could be different with the 4 channels than with 8, so the question is if it stops after a short time, if not one/ I have to adjust the initialization in the binding.
If it stops I have to look at the log if you tried to switch an output of the module to say more.
I successfully tested the 940/16 AM with different addresses. That is, I connected only the module 940/16 AM, configured the module with address 1 and could still switch outputs from openhab. Same for address 2.
I also tried the module 940/4 AM configured with address 0 and that did not work either. So I guess that the issue is with talking to 940/4 AM.
When I tried to collect the TRACE log then all AM modules started working. I think that it was a) an initialization issue (I power-cycled the modbus) or b) duplicate addresses.
I noticed that AM and EM modules have the same addresses, that is, there is an AM module with address 000000 and an EM modules with address 000000. In the STM configuration the AM module addresses start at 64. Is there something in the STM to support addresses beyond 5 bits and is such a mode supported by the phc openhab plugin?
I noticed some error messages in openhab logs when I tried to configure additional modules. Connecting only the AM modules works and connecting only the EM modules works, but I cannot have both with the same addresses connected on the bus and supported in openhab so far. I suspect that this is due to the address collisions. I will try with unique addresses for all modules next weekend.
Good, so it should basically work. It sounds a lot like option a) to me. I have also had problems with the initialling of many modules at the same time, especially with the EM, see below.
Internally the different module types have a different address space: EM 0-32, AM and JRM 64-95, DIM 160-191 (in decimal numbers), but the Bridge (STM) handles that for you. So in the config (same like the DIP switches at the modules) you can have 00000 for an EM, an AM or JRM and a DIM.
Of course I cannot say anything about the errors without seeing them but if the modules work individually they might have nothing to do with it.
The initialization process is not very robust because all modules send a lot of messages in this time.
Sometimes I have to plug in the modules, especially the EM, one after the other to get them successfully initialized.
So first only connect all AM/JRM modules and wait until no new initialization messages appear in the (debug) log. Then do the same with the EM modules, if they are not successfully initialized after a few minutes you can try it for on EM module after the other. Or the other way around, depending on the order of your modules.
The last times it also worked for me to initialize all at once, but with many modules this can take a few minutes.
From /var/log/openhab2/openhab.log:
2020-07-22 21:55:27.012 [ERROR] [org.openhab.core.model.thing ] - bundle org.openhab.core.model.thing:2.5.0 (178)[org.eclipse.smarthome.model.thing.internal.GenericThingProvider(132)] : The addThingHandlerF
actory method has thrown an exception
java.lang.IllegalArgumentException: Duplicate channels phc:JRM:10010:00
at org.eclipse.smarthome.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:165) ~[?:?]
at org.eclipse.smarthome.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:141) ~[?:?]
at org.eclipse.smarthome.core.thing.binding.builder.ThingBuilder.withChannels(ThingBuilder.java:87) ~[?:?]
at org.eclipse.smarthome.core.thing.binding.ThingFactory.createThing(ThingFactory.java:92) ~[?:?]
at org.eclipse.smarthome.core.thing.binding.BaseThingHandlerFactory.createThing(BaseThingHandlerFactory.java:332) ~[?:?]
at org.openhab.binding.phc.internal.PHCHandlerFactory.createThing(PHCHandlerFactory.java:78) ~[?:?]
at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.getThingFromThingHandlerFactory(GenericThingProvider.java:507) ~[?:?]
at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.getThingFromThingHandlerFactories(GenericThingProvider.java:490) ~[?:?]
[…]
Am I doing something wrong?
The bus contains many more modules, here is a complete things file describing the modules:
mharvan@pan:/etc/openhab2$ cat things/phc.things.full
Bridge phc:bridge:demo [port="/dev/ttyUSB0"]{
// The ThingID have to be the address.
// AM Module: Basement
Thing AM 00000 [address="00000"] // AM 0
Thing AM 10000 [address="10000"] // AM 1
Thing AM 01000 [address="01000"] // AM 2
// JRM Module: Basement
// Thing JRM 11000 [address="11000"] // JRM 3 // , upDownTime3="60", upDownTime4="20"
// Thing JRM 00100 [address="00100"] // JRM 4
// Thing JRM 10100 [address="10100"] // JRM 5
// JRM Module: Attic
// Thing JRM 01100 [address="01100"] // JRM 6
// Thing JRM 11100 [address="11100"] // JRM 7
// Thing JRM 00010 [address="00010"] // JRM 8
// Thing JRM 10010 [address="10010"] // JRM 9
// AM Module: Attic
Thing AM 01010 [address="01010"] // AM 10
Thing AM 11010 [address="11010"] // AM 11
// EM Module: Basement
Thing EM 00000 [address="00000"] // EM 0
Thing EM 10000 [address="10000"] // EM 1
Thing EM 01000 [address="01000"] // EM 2
Thing EM 11000 [address="11000"] // EM 3
Thing EM 00100 [address="00100"] // EM 4
Thing EM 00010 [address="00010"] // EM 8
// EM Module: Attic
Thing EM 10100 [address="10100"] // EM 5
Thing EM 01100 [address="01100"] // EM 6
Thing EM 11100 [address="11100"] // EM 7
// DIM Module: Basement
Thing DIM 00000 [address="00000"]
The STM was running while I was testing the config file parsing.
That looks to me like you’re trying to define this thing twice. This is not related to the addresses on PHC side but to the channel UIDs of openhab. So maybe you also created the thing in the PaperUI?
I cannot find an error in your files but I do not have much experience with the definition of things in text files. I’ve created my Things in the PaperUI and only the Items and rules in the text files. You cuold try to hide your thing text file and try to creare the Bridge and the Thing in the PaperUI to avoid configuration errors.
UPDATE: I found the error: There is an error with the channel IDs in the configuration files of the Thing types.
The error has crept in with the last update of the binding. I will correct it later.
@mharvan I’ve corrected the bug, until the PR is merged you can download it from the eclipse marketplace (see above).
The bug affect JRM and DIM modules: you can neither create JRM Things nor send commands to the DIM modules.
But it don’t affect EM and AM Things/modules. So if you don’t want to install the binding from the marketplace you can test it first with these.
I hope the PR will be included in the 2.5.8 release next month.
Thanks Jonas! I installed the version from the marketplace and now the full things and items config files including JRM modules can be parsed without the exception I got earlier.
It seems that loading of the marketplace version failed. Maybe that’s why I did not see any exceptions in my previous test. How can I install the missing dependency org.eclipse.smarthome.io.transport.serial?
2020-07-26 12:26:44.507 [WARN ] [lace.internal.BundleExtensionHandler] - Installed bundle, but failed to start it: Could not resolve module: org.openhab.binding.phc [220]
Unresolved requirement: Import-Package: org.eclipse.smarthome.io.transport.serial
Openhab can’t resolve the dependencies if you install a binding from the marketplace or a single jar from the addons folder so you have to intall them this way:
