Powermax binding

This manual only for very old PowerMax panels.

Starting from ver. 18.XXX of Power Master panels baudrate changed to 38400 (via RS232 and Plink port)

Can you please point where you find this information on the web ?
Before I spend time adding a new setting, I can compile for you a test version with 38400 hardcoded for baudrate.

Hi, I migrated OH to a RPI and now have issues with the powermax binding ( Snapshot 2.2.0 ).

Everything is working as expected, Zone Triggering is updating items etc, but after a period of time it stops updating. I can still arm and disarm the system via OH but the Powermax is not updating OH Items.

Debugging shows this…

2018-04-08 19:01:52.179 [DEBUG] [wermax.handler.PowermaxBridgeHandler] - Powermax job...

2018-04-08 19:02:12.182 [DEBUG] [wermax.handler.PowermaxBridgeHandler] - Powermax job...

2018-04-08 19:02:32.189 [DEBUG] [wermax.handler.PowermaxBridgeHandler] - Powermax job...

2018-04-08 19:02:32.194 [DEBUG] [.internal.message.PowermaxCommDriver] - sendMessage(): add message in queue (type RESTORE)

2018-04-08 19:02:32.197 [DEBUG] [.internal.message.PowermaxCommDriver] - sendMessage(): sending RESTORE message 0DAB0600000000000000000043000A

2018-04-08 19:02:52.228 [DEBUG] [wermax.handler.PowermaxBridgeHandler] - Powermax job...

2018-04-08 19:03:12.232 [DEBUG] [wermax.handler.PowermaxBridgeHandler] - Powermax job...

2018-04-08 19:03:32.238 [DEBUG] [wermax.handler.PowermaxBridgeHandler] - Powermax job...

2018-04-08 19:03:32.242 [DEBUG] [.internal.message.PowermaxCommDriver] - sendMessage(): add message in queue (type RESTORE)

2018-04-08 19:03:32.245 [DEBUG] [.internal.message.PowermaxCommDriver] - sendMessage(): sending RESTORE message 0DAB0600000000000000000043000A

2018-04-08 19:03:52.268 [DEBUG] [wermax.handler.PowermaxBridgeHandler] - Powermax job...

2018-04-08 19:04:12.272 [DEBUG] [wermax.handler.PowermaxBridgeHandler] - Powermax job...

2018-04-08 19:04:32.276 [DEBUG] [wermax.handler.PowermaxBridgeHandler] - Powermax job...

2018-04-08 19:04:32.280 [DEBUG] [.internal.message.PowermaxCommDriver] - sendMessage(): add message in queue (type RESTORE)

2018-04-08 19:04:32.284 [DEBUG] [.internal.message.PowermaxCommDriver] - sendMessage(): sending RESTORE message 0DAB0600000000000000000043000A

Using Powerlink Mode via RS232.
Can anyone help with this RESTORE message with no response from Panel.?

Mike

Just to say I belatedly migrated to the marketplace binding and it works perfectly - thank you!

Are you using a Raspberry PI?, Im still having issues, was going to remove the USB Serial Adaptor and try using one of the GPIO as serial. see if that fixes my issue.

No, a small Ubuntu 16 PC.

Hi. Sorry for my late answer, not have much time for setup my HA system…
I working near Visonic QA team. This info I received from this guys about baudrate updates in new versions of panel. My home panel I received from QA team for Alpha testing and it has one of new version. I can ask him to flash any version of panel and after testing some versions I have next results. There are:
17.133 and below - baudrate is 9600
18.045 (next released version) and above - baudrate is 38400

Can you compile version with hardcoded baudrate to 38400?
Also can you write which version your panel has?

I own a PowerMax Pro, not a Power Master model.
Is the new baudrate only applicable to Power Master models ?
The best solution would probably require a new baudrate parameter for the thing. This will take a little time to implement.
As a workaround, I will try to compile soon a new special version with new baudrate.

As I know PowerMaster panels end of life starting from 12.XXX version of panel. All 12.XXX+ versions it`s PowerMax.
Special version its good, do not rush to implement baudrate parameter. Need to test how this binding works with new version. A lot of changes were made.

@jnt2007: check your private messages, I just built the binding with 38400 as baudrate.

What’s the latest version of the binding please? and where can I pick it up?

In add-ons I can only see the 1.x version.

thanks
Colin

The 2.x version is still not yet reviewed and so not yet included officially in OH.
You can find the 2.x version in the marketplace. This is a version 2.2 that will work well with OH 2.2.
For a [http://lg.hc.free.fr/openHAB/org.openhab.binding.powermax-2.2.0-SNAPSHOT.jar](http://direct download link)

OK @Lolodomo thanks :slight_smile:

would I cause an issue if I renamed Powermax things and Items within my installation?

Sorry for being a little off topic , but does anyone know where I can still buy the Visonic Powermax RS232 kit adapter?

Let me check and see if I still have a spare

I am unable to set the alarm using:

Frame label=“Security”{
Switch item=SerialConnectionToTheAlarmSystem_SystemStatus mappings=[Disarmed=“Disarmed”, Stay=“Armed home”, Armed=“Armed away”] valuecolor=[==“Armed”=“green”, ==“Stay”=“orange”]
}

I see this in the log:

07:47:56.972 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘SerialConnectionToTheAlarmSystem_SystemStatus’ received command Stay
07:47:56.974 [DEBUG] [owermax.handler.PowermaxBridgeHandler] - Received command Stay from channel system_status
07:47:56.983 [INFO ] [smarthome.event.ItemStateChangedEvent] - SerialConnectionToTheAlarmSystem_SystemStatus changed from Disarmed, Ready, Status changed to Stay

but the alarm doesn’t set. The app/webpage updates and shows the alarm is set, until a motion sensor or something else triggers an update from the alarm to OH2, then the correct (disarmed) status gets updated.

When i use the ‘Control’ function in PaperUI, i can set the alarm using the ‘System Armed’ switch.

Arm/Disarm is set as to allow.

You are using the wrong channel. The channel to be updated is arm_mode.

Issue resolved, thanks very much Lolodomo.

For your information, the version 2.0 of the binding was just merged in the official openHAB2 repository. It will replace the version 1.x in the coming 2.4 snapshots and will be available in the next openHAB 2.4.
The version from the IoT marketplace will be removed once openHAB 2.4 is released.

3 Likes

Thats great news! I’ve been running latest 2.4 snapshot on Raspbian and it worked. However i’m migrating to docker and I couldn’t get it to work on docker with same 2.4 snapshot. It shows in the log it is connecting and connects:

19:32:20.336 [DEBUG] [nternal.handler.PowermaxBridgeHandler] - initializing handler for thing powermax:ip:home
19:32:20.355 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing ‘powermax:ip:home’ has been updated.
19:32:30.343 [DEBUG] [nternal.handler.PowermaxBridgeHandler] - Powermax job…
19:32:30.350 [DEBUG] [nternal.handler.PowermaxBridgeHandler] - trying to reconnect…
19:32:30.356 [DEBUG] [ternal.connector.PowermaxTcpConnector] - close(): Closing TCP Connection
19:32:30.362 [DEBUG] [.internal.connector.PowermaxConnector] - cleanup(): cleaning up Connection
19:32:30.367 [DEBUG] [.internal.connector.PowermaxConnector] - cleanup(): Connection Cleanup
19:32:30.376 [DEBUG] [nternal.handler.PowermaxBridgeHandler] - closeConnection(): disconnected
19:32:30.393 [DEBUG] [ternal.connector.PowermaxTcpConnector] - open(): Opening TCP Connection
19:32:30.407 [DEBUG] [nternal.handler.PowermaxBridgeHandler] - openConnection(): connected
19:32:30.408 [DEBUG] [ternal.connector.PowermaxReaderThread] - Data listener started
19:32:30.421 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - ‘powermax:ip:home’ changed from INITIALIZING to ONLINE

However none of the Zone things seem to get correctly initialized and they remain OFFLINE, small snapshot:

19:32:30.833 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - ‘powermax:zone:home:zone5’ changed from UNINITIALIZED (BRIDGE_UNINITIALIZED) to INITIALIZING
19:32:30.832 [DEBUG] [internal.handler.PowermaxThingHandler] - Set handler status to OFFLINE for thing powermax:zone:home:zone10 (zone number 10 not paired)
19:32:30.880 [DEBUG] [internal.handler.PowermaxThingHandler] - Received command REFRESH from channel low_battery
19:32:30.873 [DEBUG] [internal.handler.PowermaxThingHandler] - Set handler status to UNKNOWN for thing powermax:zone:home:zone12 (bridge ONLINE)
19:32:30.888 [DEBUG] [internal.handler.PowermaxThingHandler] - Received command REFRESH from channel bypassed
19:32:30.890 [DEBUG] [internal.handler.PowermaxThingHandler] - Set handler status to OFFLINE for thing powermax:zone:home:zone12 (zone number 12 not paired)
19:32:30.865 [DEBUG] [internal.handler.PowermaxThingHandler] - Set handler status to UNKNOWN for thing powermax:zone:home:zone11 (bridge ONLINE)
19:32:30.867 [DEBUG] [internal.handler.PowermaxThingHandler] - Initializing handler for thing powermax:zone:home:zone13
19:32:30.866 [DEBUG] [internal.handler.PowermaxThingHandler] - Set handler status to OFFLINE for thing powermax:zone:home:zone6 (zone number 6 not paired)
19:32:30.886 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - ‘powermax:zone:home:zone1’ changed from UNINITIALIZED (BRIDGE_UNINITIALIZED) to INITIALIZING
19:32:30.905 [DEBUG] [internal.handler.PowermaxThingHandler] - Set handler status to OFFLINE for thing powermax:zone:home:zone11 (zone number 11 not paired)
19:32:30.910 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - ‘powermax:zone:home:zone4’ changed from INITIALIZING to UNKNOWN
19:32:30.912 [DEBUG] [internal.handler.PowermaxThingHandler] - Set handler status to UNKNOWN for thing powermax:zone:home:zone13 (bridge ONLINE)
19:32:30.915 [DEBUG] [internal.handler.PowermaxThingHandler] - Received command REFRESH from channel armed
19:32:30.914 [DEBUG] [internal.handler.PowermaxThingHandler] - Received command REFRESH from channel tripped
19:32:30.914 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - ‘powermax:zone:home:zone3’ changed from INITIALIZING to UNKNOWN
19:32:30.938 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - ‘powermax:zone:home:zone2’ changed from INITIALIZING to UNKNOWN

Any ideas?

Also Bypassing a zone seems to work (i get SMS notification of zone bypassed from the Powermax) even when below says it’s only supported in Powerlink mode.

19:58:51.158 [DEBUG] [nternal.handler.PowermaxBridgeHandler] - Powermax job…
19:59:02.603 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘Zone8_Bypassed’ received command ON
19:59:02.614 [DEBUG] [internal.handler.PowermaxThingHandler] - Received command ON from channel bypassed
19:59:02.619 [DEBUG] [nternal.handler.PowermaxBridgeHandler] - Powermax alarm binding: Bypass option only supported in Powerlink mode
19:59:11.165 [DEBUG] [nternal.handler.PowermaxBridgeHandler] - Powermax job…

However arming/downloading/getting logs results in exceptions like:

19:58:40.083 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘SystemArmed’ received command ON
19:58:40.098 [DEBUG] [nternal.handler.PowermaxBridgeHandler] - Received command ON from channel system_armed
19:58:40.106 [ERROR] [rnal.common.AbstractInvocationHandler] - An error occurred while calling method ‘ThingHandler.handleCommand()’ on ‘org.openhab.binding.powermax.internal.handler.PowermaxBridgeHandler@c8a88f’: null
java.lang.NullPointerException: null
at org.openhab.binding.powermax.internal.handler.PowermaxBridgeHandler.armCommand(PowermaxBridgeHandler.java:338) ~[?:?]
at org.openhab.binding.powermax.internal.handler.PowermaxBridgeHandler.handleCommand(PowermaxBridgeHandler.java:310) ~[?:?]
at sun.reflect.GeneratedMethodAccessor79.invoke(Unknown Source) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [101:org.eclipse.smarthome.core:0.10.0.201809271800]
at org.eclipse.smarthome.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [101:org.eclipse.smarthome.core:0.10.0.201809271800]
at com.sun.proxy.$Proxy141.handleCommand(Unknown Source) [232:org.openhab.binding.powermax:2.4.0.201810032130]
at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:75) [107:org.eclipse.smarthome.core.thing:0.10.0.201809271800]
at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:49) [107:org.eclipse.smarthome.core.thing:0.10.0.201809271800]
at sun.reflect.GeneratedMethodAccessor78.invoke(Unknown Source) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [101:org.eclipse.smarthome.core:0.10.0.201809271800]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [101:org.eclipse.smarthome.core:0.10.0.201809271800]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]