Satel binding - support, announcements and feature requests

Add-ons Bindings
101

Hi, I have this configuration in files.

ubuntu@a2:~$ cat /opt/openhab2/conf/items/satel.items 
Group Satel
Group:Switch:OR(ON,OFF) Alarms "Alarms [(%d)]" <siren>
Switch PARTITION_ARMED "Partition armed" (Satel) { channel="satel:partition:home:MainPartition:armed" }
Switch PARTITION_ALARM "Partition alarm" (Satel,Alarms) { channel="satel:partition:home:MainPartition:alarm" }
Switch PARTITION_ALARM_M "Partition alarm memory" (Satel,Alarms) { channel="satel:partition:home:MainPartition:alarm_memory" }
Switch ZONE1_VIOLATION "Engine Running" (Satel) { channel="satel:zone:home:Zone1:violation" }
Switch ZONE2_VIOLATION "Low Fuel" (Satel) { channel="satel:zone:home:Zone2:violation" }
Switch ZONE3_VIOLATION "General Error" (Satel) { channel="satel:zone:home:Zone3:violation" }
Switch ZONE4_VIOLATION "Zone4-MG1 Violation" (Satel) { channel="satel:zone:home:Zone4:violation" }
Switch ZONE5_VIOLATION "Zone5-MG2 Violation" (Satel) { channel="satel:zone:home:Zone5:violation" }
Switch ZONE6_VIOLATION "Zone6-MG3 Violation" (Satel) { channel="satel:zone:home:Zone6:violation" }
Switch ZONE7_VIOLATION "Zone7-TEMP Violation" (Satel) { channel="satel:zone:home:Zone7:violation" }
Switch ZONE17_VIOLATION "Zone17-PIR1 Violation" (Satel) { channel="satel:zone:home:Zone17:violation" }
Switch ZONE18_VIOLATION "Zone18 Violation" (Satel) { channel="satel:zone:home:Zone18:violation" }
Switch ZONE19_VIOLATION "Zone19-PIR2 Violation" (Satel) { channel="satel:zone:home:Zone19:violation" }
Switch ZONE20_VIOLATION "Zone20 Violation" (Satel) { channel="satel:zone:home:Zone20:violation" }
Switch ZONE21_VIOLATION "Zone21-PIR3 Violation" (Satel) { channel="satel:zone:home:Zone21:violation" }
Switch ZONE22_VIOLATION "Zone22 Violation" (Satel) { channel="satel:zone:home:Zone22:violation" }
Switch ZONE23_VIOLATION "Zone23-PIR4 Violation" (Satel) { channel="satel:zone:home:Zone23:violation" }
Switch ZONE24_VIOLATION "Zone24 Violation" (Satel) { channel="satel:zone:home:Zone24:violation" }
Switch OUT2 "Gen. Start" (Satel) { channel="satel:output:home:Out2:state" }
Switch OUT4 "Gen. Mode" (Satel) { channel="satel:output:home:Out4:state" }
Switch OUT5 "Gen. Restart" (Satel) { channel="satel:output:home:Out5:state" }
Switch SYSTEM_TROUBLES "Panel Troubles" (Satel) { channel="satel:system:home:System:troubles" }
String KEYPAD_CHAR ">" <none> (Satel)
String USER_CODE "User code" (Satel) { channel="satel:system:home:System:user_code" }
Number EVENT_LOG_IDX "Event log - current index [%d]" (Satel) { channel="satel:event-log:home:EventLog:index" }
Number EVENT_LOG_PREV "Event log - previous index [%d]" (Satel) { channel="satel:event-log:home:EventLog:prev_index" }
DateTime EVENT_LOG_TIME "Event log - time [%1$tF %1$tR]" (Satel) { channel="satel:event-log:home:EventLog:timestamp" }
String EVENT_LOG_DESCR "Event log - description [%s]" (Satel) { channel="satel:event-log:home:EventLog:description" }
String EVENT_LOG_DET "Event log - details [%s]" (Satel) { channel="satel:event-log:home:EventLog:details" }
Switch MODULE_CONNECTED "Connection status" <network> (Satel)
DateTime MODULE_CONNECTED_SINCE "Connection established at [%1$tF %1$tR]" <time> (Satel)
Number MODULE_CONNECTION_ERRORS "Connection errors [%d]" (Satel)

ubuntu@a2:~$ cat /opt/openhab2/conf/things/satel.things 
Bridge satel:ethm-1:home [ host="10.0.20.10", refresh=1000, userCode="1234", encryptionKey="" ] {
    Thing partition MainPartition [ id=1 ]
    Thing zone Zone1 [ id=1 ]
    Thing zone Zone2 [ id=3 ]
    Thing zone Zone3 [ id=2 ]
    Thing zone Zone4 [ id=4 ]
    Thing zone Zone5 [ id=5 ]
    Thing zone Zone6 [ id=6 ]
    Thing zone Zone7 [ id=7 ]
    Thing zone Zone7 [ id=8 ]
    Thing zone Zone17 [ id=17 ]
    Thing zone Zone18 [ id=18 ]    
    Thing zone Zone19 [ id=19 ]
    Thing zone Zone20 [ id=20 ]
    Thing zone Zone21 [ id=21 ]
    Thing zone Zone22 [ id=22 ]
    Thing zone Zone23 [ id=23 ]
    Thing zone Zone24 [ id=24 ]
    Thing output Out2 [ id=2 ]
    Thing output Out4 [ id=4 ]
    Thing output Out5 [ id=5 ]
    Thing system System [ ]
    Thing event-log EventLog [ ]
}
102

Hi @Lukas_Zich ,
enable please DEBUG logging level and post here commands sent to Integra system. Without this I cannot help further.

103

log:set DEBUG org.openhab.binding.satel

15:59:18.526 [DEBUG] [.satel.internal.event.EventDispatcher] - Distributing event: NewStatesEvent: changed = [01,02,03,04,05,06,07,08,0A,0B,0C,0D,0E,0F,10,11,12,14,16,18,19,1B,1C,1D,1E,1F,20,21,22,23,24,25,26,27]
15:59:19.170 [DEBUG] [g.satel.internal.protocol.SatelModule] - Sending message: Message: command = 7F, payload = 
15:59:19.477 [DEBUG] [g.satel.internal.protocol.SatelModule] - Got response: Message: command = 7F, payload = FE FD 57 FB FF
15:59:19.477 [DEBUG] [.satel.internal.event.EventDispatcher] - Distributing event: NewStatesEvent: changed = [01,02,03,04,05,06,07,08,0A,0B,0C,0D,0E,0F,10,11,12,14,16,18,19,1B,1C,1D,1E,1F,20,21,22,23,24,25,26,27]
15:59:19.782 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'PARTITION_ALARM_M' received command ON
15:59:19.784 [DEBUG] [el.internal.handler.SatelThingHandler] - New command for satel:partition:home:MainPartition:alarm_memory: ON
15:59:19.788 [INFO ] [arthome.event.ItemStatePredictedEvent] - PARTITION_ALARM_M predicted to become ON
15:59:19.795 [INFO ] [home.event.GroupItemStateChangedEvent] - Alarms changed from OFF to ON through PARTITION_ALARM_M
15:59:19.801 [INFO ] [smarthome.event.ItemStateChangedEvent] - PARTITION_ALARM_M changed from OFF to ON
15:59:19.825 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'EVENT_LOG_IDX' received command -1
15:59:19.828 [INFO ] [arthome.event.ItemStatePredictedEvent] - EVENT_LOG_IDX predicted to become NULL
15:59:20.170 [DEBUG] [g.satel.internal.protocol.SatelModule] - Sending message: Message: command = 7F, payload = 
15:59:20.495 [DEBUG] [g.satel.internal.protocol.SatelModule] - Got response: Message: command = 7F, payload = FE FD 57 FB FF
15:59:20.496 [DEBUG] [.satel.internal.event.EventDispatcher] - Distributing event: NewStatesEvent: changed = [01,02,03,04,05,06,07,08,0A,0B,0C,0D,0E,0F,10,11,12,14,16,18,19,1B,1C,1D,1E,1F,20,21,22,23,24,25,26,27]
15:59:21.170 [DEBUG] [g.satel.internal.protocol.SatelModule] - Sending message: Message: command = 7F, payload = 
15:59:21.499 [DEBUG] [g.satel.internal.protocol.SatelModule] - Got response: Message: command = 7F, payload = FE FD 57 FB FF
15:59:21.499 [DEBUG] [.satel.internal.event.EventDispatcher] - Distributing event: NewStatesEvent: changed = [01,02,03,04,05,06,07,08,0A,0B,0C,0D,0E,0F,10,11,12,14,16,18,19,1B,1C,1D,1E,1F,20,21,22,23,24,25,26,27]
15:59:22.171 [DEBUG] [g.satel.internal.protocol.SatelModule] - Sending message: Message: command = 7F, payload =
104

Definitely the binding does not send event log commands to the system.
There might be several reasons:

  • you are using wrong version of the binding, please confirm it with command bundle:list | grep Satel
  • your configuration has a typo, but actually I don’t see any
  • wrong user code, please double check it is correct
  • weird OH2 state, sometimes restart helps
105

Hello,

First of all, thanks for developing such an binding. I really know, that this takes a lot of time.
Most of time I use this binding to get violation informations in openHAB from my windows- and doorsensors.

Regarding the Arming Mode I have one problem.

When I activate my alarm-system in arming-mode 2 or arming-mode 3 everything works perfect.
The two channels “armed_mode_2” and “armed_mode_3” get the correct information and switch from OFF to ON after arming the system.

The arming-mode 1 doesn’t work for me.
After arming my alarm system in arming-mode 1, the channel “armed_mode_1” doesn’t change from OFF to ON. Unfortunately there is no change ;-(

The channel “armed” changes the status from OFF to ON in every kind of arming the system (mode0/1/2 and 3).
However, i want to check exactly the arming-mode 1 and get the correct status for this.

Anyone an idea, whats the problem?
I have an integra 32 alarm system with the latest firmware and I installed the latest satel binding directly from 2.5 openHAB Snapshot.

Many Thanks and best regards
Christian

106

Hey @curius
Is there anything suspicious in the log when you arm in mode 1? Enable debug and repeat arming. Check the logs for any unexpected message.
Also this command is not supported by old INT-RS v1 module. What kind of communication module do you have?

107

Hey,

thanks for your fast reply

I enabled the debug and repeated arming the alarm system in Mode 1 over the Satel Panel.
There are no suspicious informations in the log. Only the channel for “armed” (mode 0) changes from OFF to ON. No change for the channel “arming_mode_1”.

When I activate the arming mode 1 over the OpenHab Sitemap, the channel “armed_mode_1” changes from OFF to ON correctly but changes back again after 1 second from ON to OFF.

I connect to my alarm system over the ETHM-1 Plus Modul (latest Firmware).
It’s very strange because mode 2 and mode 3 works perfect for me. Only mode 1 makes troubles


Best regards
Christian

108

Thanks for the info, I will try to reproduce this on my system. The code seems to be OK, but I have never used arming in mode 1 actually.

109

Hello,

many thanks for your information and your support

Let me know if you need any additional informations or log-files from my side.

Best regards
Christian

110

I did a quick test and it seems to work properly. The system didn’t arm, because there were few violations in the system, but the command has been issued. Here is the log:

2019-08-21 18:16:14.197 [DEBUG] [.satel.internal.protocol.SatelModule] - Sending message: Message: command = 81, payload = XX XX XX XX ...
2019-08-21 18:16:14.198 [DEBUG] [.satel.internal.protocol.Ethm1Module] - Encrypting data: XXXXXX...
2019-08-21 18:16:15.253 [DEBUG] [.satel.internal.protocol.Ethm1Module] - Decrypted data: XXXXXX...
2019-08-21 18:16:15.253 [DEBUG] [.satel.internal.protocol.SatelModule] - Got response: Message: command = EF, payload = 12
2019-08-21 18:16:15.254 [INFO ] [el.internal.command.SatelCommandBase] - Can not arm. Message: command = 81, payload = XX XX XX XX ...

If you don’t have such entries in your log, maybe there is something wrong with your configuration.

111

Hello,

thanks for your support and your quick test.
My log nearly looks like yours:

21:30:10.914 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'Armed_ext1' received command ON
21:30:10.920 [INFO ] [arthome.event.ItemStatePredictedEvent] - Armed_ext1 predicted to become ON
21:30:10.953 [DEBUG] [ternal.handler.SatelStateThingHandler] - New command for satel:partition:home:Haus:armed_mode_1: ON
21:30:10.961 [DEBUG] [g.satel.internal.protocol.SatelModule] - Sending message: Message: command = 81, payload = XX XX XX XX XX XX XX XX XX XX XX XX
21:30:10.967 [DEBUG] [g.satel.internal.protocol.Ethm1Module] - Encrypting data: XXX...
21:30:10.985 [INFO ] [smarthome.event.ItemStateChangedEvent] - Armed_ext1 changed from OFF to ON
21:30:11.852 [DEBUG] [g.satel.internal.protocol.Ethm1Module] - Decrypted data: XXX...
21:30:11.859 [DEBUG] [g.satel.internal.protocol.SatelModule] - Got response: Message: command = EF, payload = 00
21:30:12.868 [DEBUG] [.satel.internal.event.EventDispatcher] - Distributing event: NewStatesEvent: changed = [09,0A,0B,0C,0D,0E,0F,10,11,12,13,14,15,16,25,27,2A,2B]
21:30:12.892 [DEBUG] [g.satel.internal.protocol.SatelModule] - Sending message: Message: command = 09, payload = 
21:30:12.899 [DEBUG] [g.satel.internal.protocol.Ethm1Module] - Encrypting data: XXX...
21:30:13.032 [DEBUG] [g.satel.internal.protocol.Ethm1Module] - Decrypted data: XXX...
21:30:13.039 [DEBUG] [g.satel.internal.protocol.SatelModule] - Got response: Message: command = 09, payload = 00 00 00 00
21:30:13.046 [DEBUG] [.satel.internal.event.EventDispatcher] - Distributing event: IntegraStateEvent: command = 09, extended = false, active = {}
21:30:13.055 [DEBUG] [g.satel.internal.protocol.SatelModule] - Sending message: Message: command = 2A, payload = 
21:30:13.062 [DEBUG] [g.satel.internal.protocol.Ethm1Module] - Encrypting data: XXX...
21:30:13.282 [DEBUG] [g.satel.internal.protocol.Ethm1Module] - Decrypted data: XXX...
21:30:13.289 [DEBUG] [g.satel.internal.protocol.SatelModule] - Got response: Message: command = 2A, payload = 00 00 00 00
21:30:13.296 [DEBUG] [.satel.internal.event.EventDispatcher] - Distributing event: IntegraStateEvent: command = 2A, extended = false, active = {}
21:30:13.307 [DEBUG] [g.satel.internal.protocol.SatelModule] - Sending message: Message: command = 0B, payload = 
21:30:13.311 [INFO ] [smarthome.event.ItemStateChangedEvent] - Armed_ext1 changed from ON to OFF

You can see, that the item “Armed_ext1” correctly changes from OFF to ON and after about 3 seconds it changes back to the state OFF.
I can’t see any reason for this behavior.

Nevertheless, thanks for your fast reply

Please let me know if you have any additional ideas or comments reffering to my log file.

Best regards
Chris

112

There are two important messages in this case:

  • 81 arms a partition in mode 1, first 8 payload bytes contain pin code, last 4 bytes are partitions you want to arm (check if the message is correct),
  • 2A gets list of partitions armed in mode 1, again 4 payload bytes represents partitions - when bit is ‘1’, than this particular partition is armed in mode 1.

As you can see the binding sends 81 command and the system returns EF 00 - which means ‘accepted’. But next we have 2A with 00 00 00 00 in response payload, which means ‘no partitions armed in mode 1’.
Either this is a bug in Satel firmware, or maybe this partition cannot be armed for some reason.

Have you tried to arm in mode 1 manually from the panel? What was the result?

113

Yes, I can arm the system manually from the panel (mode 1), with the result, that the alarm-system is correctly armed in mode 1.

Nevertheless changes the switch back to the state OFF although the system is armed.

Thanks for your additional informations. I will check my configuration again. Maybe I can find any failures or problems.

Best regards
Christian

114

I did another test and definitely it works for me. I can arm and disarm in mode 1 without problems.

115

Thank you very much for your efforts and your support!
So I need to check my configuration of the alarm-system


Best regards
Chris

116

Hello all!
I’ve got good news: another PR has been merged into master and next is prepared for approval.

Once we have it merged, all features from the testing version of the binding will be available in OH nightly snapshots.

1 Like
117

Hi @druciak. I am now trying to integrate my Satel Integra using this binding and it looks like I have the same issue as @curius. Arming the system in Mode 1 is actually working, but the switch linked to te armed_mode_1 channel goes back and/or is not updated. Also when arming the system from a normal panel this switch is not enabled.

I tried to understand the log and had a look in de protocol description. The protocol description has a note that for INT-RS v2.xx the 0X7F cmd has an additional byte (5+1). This additional byte indicates whether there is data available for the 0x2A cmd (which is actually the cmd to get partitions armed in Mode 1). The log only shows 5 bytes so perhaps that is the reason this isn’t working as expected now?

I also tried to arm mode 2, this is working as this is not in the 6th byte.

Does this sound feasible?

118

Hi @petermdevries
You might be right. For some reason I missed that info. Implemented logic for using “extended” commands does not fit in this case and must be changed. Likely, after connection is established version of the module must be retrieved using 0x7c command and basing on the response either send or not additional byte in 0x7f command.

I will look into this soon, hopefully this is the solution to your issue. Thanks looking into this. :slight_smile:

1 Like
119

However this is something else @curius encounters. In his case 2A command is issued, but the response does not have relevant bits set. Anyway the binding must be fixed.

If I did complete test of arming in mode 1 it would show the issue, :frowning:

120

New version availeble at the Marketplace. It fixes issues with refreshing arming state in mode 1.

Enjoy :slight_smile:

@curius and @petermdevries I hope you find some time to give it a try.