Just removed the old 1.x binding and gave the latest snapshot a try.
Installed fine, and just added the serial connection via PaperUI. All zones were detected, everything worked brilliantly.
This is on OpenHAB 2.2.0 snapshot. Going to be testing it out and building some rules over the next week or so.
Thanks for making the snapshot available, @Lolodomo.
Hi,
Did any owner of the powermaster 10 model manage to have the binding fully working?
I’m using the 2.1 version of the binding, I can arm/disarm and get events from door contacts for example, but often events are not reported.
Also, when reported, openhab detects the event after 1-2 minutes, is this delay normal?
Thanks!
nope - for me reporting is almost immediate. Am using Powermax Pro and OH2.1 but with legacy 1.x binding.
You should have immediate state changes when using standard UIs. For motion sensors, the return to state CLOSED occurs after a fixed delay of 3 minutes.
Thanks for the replies!
Then I have either a problem in my setup (didn’t find any so far) or the powermaster 10 is not fully supported.
I will try to do some debugging and see what I find.
Hi @Lolodomo I’ve been quite busy and I have had no time to work on this, but now I can spend some time debugging my issue.
I’ve checked all the cabling and it’s correct. If I plug the USB2SERIAL adapter in my Windows machine with the Visonic Software it works well.
I’ve been trying to understand PowerMax Serial protocol and i found the way to calculate de checksum and some info about the messages.
If I dismiss the checksum error, the message that repeats in my log every 30 sec decodes as follows, and it makes sense and “proves” that serial connection is working propoerlly
Msg=0d-a5-00-02-00-00-00-00-00-00-00-00-43-0a
Decodes as:
0d Preamble
a5-00 General Event Descripction
02 Keep alive
00- Zone 1-8 Status (ok)
00- Zone 9-16 Status (ok)
00- Zone 17-24 Status (ok)
00- Zone 25-30 Status (ok)
00- Battery Zones 1-8 Status (ok)
00- Battery Zones 9-16 Status (ok)
00- Battery Zones 17-24 Status (ok)
00- Battery Zones 25-30 Status (ok)
43- Fixed EOM
16- Checksum
0A Postamble
This seems like a normal Keep-alive message, but if I calculate the checksum as stated in the docs I get the same result you get: 0x15, but the message states 0x16 as its checksum???. As this is a regular message, can someone check if his alarm sends this message every 30 sec with checksum 0x15?? This will mean that for some reason my alarm is incrrectly calculating this checksum (which seem extrange to me??)
The other message that I see in my log is 0DAB03001E00312E3038000043290A but I’ve been unable to find the meeing of the 0XAB Message .
In order to continue @lolodomo, could you add a flag or something in the config of the binding to disable checksum verification? I use to have all the eclipse enviroment ready to compile OH bindings, but I’ve changed my laptop and I haven’t do it already and setting it up properly takes a while…
Thx in advance for your help
Regards
Chano
Hi @Lolodomo, finally I’ve been able to compile your OH1 binding with a slight change in PowerMaxReaderThread.java in line 170 to accept messages which CRC is the correct minus 1.
This is what I’ve added:
if (checksum == expected -1)
{
byte[] logData = Arrays.copyOf(data, len);
logger.warn("Almost... expected CRC {}, got {}, msg {}.Fixing...",String.format("%02X", expected), String.format("%02X", checksum),DatatypeConverter.printHexBinary(logData));
checksum=expected;
}
Now it seems to go further, but still I cannot see any of the items I’ve defined (just a couple, panel_eprom and another one.
I’ve been trying to follow the code and I’ve found something that look strange to me. In my log, when I get one of this wrong CRC messages I see:
2017-08-29 19:11:30.794 [WARN ] [ernal.connector.PowerMaxReaderThread] - Almost... expected CRC 29, got 28, msg 0DAB03001E00312E3038000043290A.Fixing...
2017-08-29 19:11:30.798 [DEBUG] [ng.powermax.internal.PowerMaxBinding] - powerMaxEventReceived(): received message POWERLINK
2017-08-29 19:11:30.800 [DEBUG] [internal.message.PowerMaxBaseMessage] - message handled by class PowerMaxBaseMessage:
- Raw data = 0DAB03001E00312E3038000043290A
- type = AB ( POWERLINK )
As you can see this log message states that is going to be handled by PowerMaxBaseMessage.class, but in PowerMaxReceiveType.jave states that 0xAB messages should be treated by class PowerMaxPowerlinkMessage.class
POWERLINK((byte) 0xAB, 15, false, PowerMaxPowerlinkMessage.class),
Does this make sense to you?
Thx again for your help
Regards
@chano: I just take a look to my OH2 code and I see no reason to have the message handled by PowerMaxBaseMessage rather than PowerMaxPowerlinkMessage. Maybe you can add debug logs in PowermaxBaseMessage getMessageObject to understand what exception leads to the use of PowermaxBaseMessage.
This message is a keep alive message so normally the panel is expecting an ACK.
I believe I have sometimes this checksum error (at least in the past) but only once when the binding is started I think. Not handling this message seems to be without any consequence for me.
@Lolodomo: I’m testing the 2.1.0 snapshot without success. download_setup fails with:
2017-09-13 14:37:03.416 [INFO ] [wermax.handler.PowermaxBridgeHandler] - Powermax alarm binding: download setup only supported in Powerlink mode
My setup is using the “IP connection to the alarm system” in the following hardware setup
Powermax RS232 Kit for UC232R-10 ser2net on Openhab 2.1.0 on
Complete <--> Powermax Pro & Complete <--> USB/RS232 <--> OpenWRT <--> Openhabian
Converter NSLU2 Raspberry Pi3
This setup works with the 1.10.0 powermax binding (and was previously used with a Vera3 on UI5 and the Mios Powermax plugin in powerlink mode)
The 1.10.0 version has been uninstalled and Openhab2 restarted and the 2.1.0 snapshot version dropped in the addons folder
From the logs I assume the connections kind of work (Also the Panel has stopped calling my mobile with “Tamper alerts” - So the communications seems to be restored with the new binding) - But not in powerlink mode:
2017-09-13 14:17:11.611 [INFO ] [wermax.handler.PowermaxBridgeHandler] - Powermax alarm binding: TCP connection (IP 192.168.86.205 port 3481): connected
2017-09-13 14:20:11.634 [DEBUG] [wermax.handler.PowermaxBridgeHandler] - Powermax job...
2017-09-13 14:20:31.639 [DEBUG] [wermax.handler.PowermaxBridgeHandler] - Powermax job...
2017-09-13 14:20:33.095 [DEBUG] [x.discovery.PowermaxDiscoveryService] - Updating discovered things (new scan)
2017-09-13 14:20:51.643 [DEBUG] [wermax.handler.PowermaxBridgeHandler] - Powermax job...
2017-09-13 14:21:11.646 [DEBUG] [wermax.handler.PowermaxBridgeHandler] - Powermax job...
...
2017-09-13 14:36:31.769 [DEBUG] [wermax.handler.PowermaxBridgeHandler] - Powermax job...
2017-09-13 14:36:51.772 [DEBUG] [wermax.handler.PowermaxBridgeHandler] - Powermax job...
2017-09-13 14:37:03.416 [INFO ] [wermax.handler.PowermaxBridgeHandler] - Powermax alarm binding: download setup only supported in Powerlink mode
2017-09-13 14:37:11.774 [DEBUG] [wermax.handler.PowermaxBridgeHandler] - Powermax job...
2017-09-13 14:37:31.777 [DEBUG] [wermax.handler.PowermaxBridgeHandler] - Powermax job...
Any advice to how I can debug this further?
Powerlink mode is needed for auto discovery, correct?
And the 1.10.0 version did run in Powerlink mode
Thansk!
What is the setup of your thing (bridge) ? Please check that you did not enable the standard mode (one of the settings).
For TCP connection, I will advice to download and use the last binding version
@hhg : the message “Powermax alarm binding: download setup only supported in Powerlink mode” should only appear because you requested this download either through the console command or the dedicated item. Can you confirm that this is the result of one of your actions ?
Apparently, the powerlink mode is not activated by the binding in your case.
Please enable the DEBUG logs: log:set DEBUG org.openhab.binding.powermax and use the 2.2 version I provided.
Hi @Lolodomo
Thanks for your quick response - and great work with this binding
Yes, I issued the download_setup from the karaf console
With the new 2.2.0 snapshot of the binding I get more or less the same result. I’m still running OpenHAB 2.1 - Do I need to switch to a 2.2. snapshot ?
My binding config - Not forced to standard mode:
This is the log when OpenHAB starts:
2017-09-14 11:05:52.754 [DEBUG] [org.openhab.binding.powermax ] - BundleEvent STARTING - org.openhab.binding.powermax
2017-09-14 11:05:52.781 [DEBUG] [org.openhab.binding.powermax ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.io.console.extensions.ConsoleCommandExtension}={component.name=binding.powermax.console, component.id=185, service.id=313, service.bundleid=199, service.scope=bundle} - org.openhab.binding.powermax
2017-09-14 11:05:52.900 [DEBUG] [org.openhab.binding.powermax ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.ThingHandlerFactory}={component.name=binding.powermax, component.id=186, service.id=314, service.bundleid=199, service.scope=bundle} - org.openhab.binding.powermax
2017-09-14 11:05:52.904 [DEBUG] [org.openhab.binding.powermax ] - BundleEvent STARTED - org.openhab.binding.powermax
2017-09-14 11:05:53.035 [DEBUG] [org.openhab.binding.powermax ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService}={service.id=316, service.bundleid=199, service.scope=singleton} - org.openhab.binding.powermax
2017-09-14 11:05:53.073 [DEBUG] [wermax.handler.PowermaxBridgeHandler] - initializing handler for thing powermax:ip:44e97e7c
2017-09-14 11:05:53.077 [hingStatusInfoChangedEvent] - 'powermax:ip:44e97e7c' changed from UNINITIALIZED to INITIALIZING
2017-09-14 11:06:03.127 [DEBUG] [wermax.handler.PowermaxBridgeHandler] - Powermax job...
2017-09-14 11:06:03.144 [DEBUG] [wermax.handler.PowermaxBridgeHandler] - trying to reconnect...
2017-09-14 11:06:03.145 [DEBUG] [wermax.handler.PowermaxBridgeHandler] - closeConnection(): disconnected
2017-09-14 11:06:03.167 [DEBUG] [ernal.connector.PowermaxTcpConnector] - open(): Opening TCP Connection
2017-09-14 11:06:03.174 [DEBUG] [ernal.connector.PowermaxReaderThread] - Data listener started
2017-09-14 11:06:03.174 [INFO ] [wermax.handler.PowermaxBridgeHandler] - Powermax alarm binding: TCP connection (IP 192.168.86.205 port 3481): connected
2017-09-14 11:06:03.175 [DEBUG] [wermax.handler.PowermaxBridgeHandler] - openConnection(): connected
2017-09-14 11:06:03.187 [DEBUG] [ernal.connector.PowermaxReaderThread] - Data listener stopped
2017-09-14 11:06:03.189 [DEBUG] [.internal.message.PowermaxCommDriver] - sendMessage(): add message in queue (type DOWNLOAD)
2017-09-14 11:06:03.196 [DEBUG] [.internal.message.PowermaxCommDriver] - sendMessage(): sending DOWNLOAD message 0D2400004F48000000000000000A
2017-09-14 11:06:03.200 [hingStatusInfoChangedEvent] - 'powermax:ip:44e97e7c' changed from INITIALIZING to ONLINE
2017-09-14 11:06:23.198 [DEBUG] [wermax.handler.PowermaxBridgeHandler] - Powermax job...
2017-09-14 11:06:43.201 [DEBUG] [wermax.handler.PowermaxBridgeHandler] - Powermax job...
2017-09-14 11:07:03.230 [DEBUG] [wermax.handler.PowermaxBridgeHandler] - Powermax job...
Download setup from the console:
openhab> smarthome:powermax powermax:ip:44e97e7c download_setup
Command 'download_setup' handled.
openhab> smarthome:powermax powermax:ip:44e97e7c info_setup
Powermax alarm binding:
Panel is of type PowerMaxCompletePart
Bell time: 4 minutes
Silent panic: disabled
Quick arm: disabled
Zone bypass: disabled
EPROM: Undefined
SW: Undefined
Serial: Undefined
Use partitions: disabled
Number of partitions: 1
openhab>
Results in the not in powerlink mode message:
2017-09-14 11:10:00.773 [INFO ] [wermax.handler.PowermaxBridgeHandler] - Powermax alarm binding: download setup only supported in Powerlink mode
Does this make sense to you?
As mentioned, with version 1.10 it works is in Powerlink mode as reported by this item:
String Powermax_panel_mode "Panel mode [%s]" (GPowerMax) {powermax="panel_mode"}
Thanks again for your help
Regards
Ok it looks like the thread reading data from the.alarm system is stopped immediately, probably due to the read method returning -1.
I will try to fix that, stay online.
You confirm the exactly same hardware, IP and port is working with the 1.x binding ?
By the way, I am very happy to have a first feedback of a user using the IP interface.
There was a change in the read method, blocking read in 1.x binding, not blocking read in 2.x. Something is certainly wrong in my TCP code.
On what OS is running your openHAB ?
@hhg : please download again the 2.2 version (same link) and test it. I updated it in such a way that TCP connection should work now.
For your information, the binding is now available in the Eclipse marketplace. It is the last version with probable fixed TCP communications.
Hi @Lolodomo
I’ve just tried git clone https://github.com/lolodomo/openhab2-addons.git to redo my CRC fix but once it finished I have the full OH2 binding sources but your powermax binding is missing??
Could you please check.
This is an ls of the addons/bindings dir right after git clone
create_openhab_binding_skeleton.cmd org.openhab.binding.hdanywhere org.openhab.binding.milight org.openhab.binding.rme org.openhab.binding.vitotronic
create_openhab_binding_skeleton.sh org.openhab.binding.homematic org.openhab.binding.netatmo org.openhab.binding.samsungtv org.openhab.binding.yamahareceiver
org.openhab.binding.astro org.openhab.binding.ipp org.openhab.binding.network org.openhab.binding.smaenergymeter org.openhab.binding.zwave
org.openhab.binding.autelis org.openhab.binding.keba org.openhab.binding.opensprinkler org.openhab.binding.squeezebox org.openhab.binding.zwave.test
org.openhab.binding.avmfritz org.openhab.binding.kostalinverter org.openhab.binding.orvibo org.openhab.binding.systeminfo pom.xml
org.openhab.binding.dscalarm org.openhab.binding.lutron org.openhab.binding.pioneeravr org.openhab.binding.systeminfo.test
org.openhab.binding.freebox org.openhab.binding.max org.openhab.binding.pulseaudio org.openhab.binding.tesla
org.openhab.binding.harmonyhub org.openhab.binding.max.test org.openhab.binding.rfxcom org.openhab.binding.urtsi
The binding code is in a branch named powemax.
Sorry, I should have realized it was a branch!
Downloaded and compiled OK. Now, I’m going to do my changes.
Thx again!
Do you have finally changes that make the binding working in your personal case ?