Satel binding - support, announcements and feature requests

Add-ons Bindings
211

Yes, input zone no 10 and partition 1.

212

Hi! Is there any chance to use Satel Binding with Integra System connected via INT-GSM?
I have remote access to the system via Integra Control app using “Satel Server”.

Can I use the “Satel Server” in the binding?

213

Hello Piotr.
I don’t think it supports integration protocol used in the binding. At least there is no mention about it on Satel web site.

214

I have the same issue with newest version of binding from marketplace:

openhab> bundle:list | grep Satel
302 │ Active │ 80 │ 2.5.9.202009031938 │ openHAB Add-ons :: Bundles :: Satel Binding

I have Satel ETHM-1 firmware 1.7

Ɓączę z serwerem: 192.168.2.XXX:ZZZ
Nawiązuje poƂączenie
ModuƂ: ETHM-1 V1.07
Jest poƂączenie.
PoƂączenie TCP/IP: 00:02:16

in my things file i have set option extCommands to false:

Bridge satel:ethm-1:dom [ host=“192.168.2.XXX”, port=“ZZZ”, refresh=1000, userCode=“YYYY”, extCommands=“false” ]

and still reconnect loop in logs

2020-09-08 10:42:22.965 [INFO ] [.satel.internal.protocol.Ethm1Module] - Connecting to ETHM-1 module at 192.168.2.XXX:ZZZ
2020-09-08 10:42:22.977 [INFO ] [.satel.internal.protocol.Ethm1Module] - ETHM-1 module connected successfully
2020-09-08 10:42:22.977 [DEBUG] [.satel.internal.protocol.SatelModule] - Sending message: Message: command = 7E, payload =
2020-09-08 10:42:22.977 [TRACE] [satel.internal.protocol.SatelMessage] - Calculated checksum = D860
2020-09-08 10:42:22.977 [TRACE] [.satel.internal.protocol.SatelModule] - Waiting for response
2020-09-08 10:42:22.991 [INFO ] [.satel.internal.protocol.Ethm1Module] - Closing connection to ETHM-1 module
2020-09-08 10:42:22.991 [DEBUG] [satel.internal.event.EventDispatcher] - Distributing event: org.openhab.binding.satel.internal.event.ConnectionStatusEvent: connected = false, reason = null
2020-09-08 10:42:22.991 [TRACE] [satel.internal.event.EventDispatcher] - Distributing to org.openhab.binding.satel.internal.protocol.Ethm1Module@4bbaaa90
2020-09-08 10:42:22.991 [TRACE] [satel.internal.event.EventDispatcher] - Distributing to org.openhab.binding.satel.internal.handler.Ethm1BridgeHandler@60ce80b3
2020-09-08 10:42:22.992 [DEBUG] [.satel.internal.protocol.SatelModule] - Communication thread stopped

I checked also config with extCommands set to true but nothing changed, same errors.

System (2.5.8 in docker) is set up from scratch, only few bindings, no sitemap, no rules. Just after 2.5.8 binding installation, connection was working but from today morning it suddenly stopped and reconnect loop appeared. Any help would be appreciated :slight_smile:

215

Is this the only client connection to ETHM-1 using integration protocol? Only one client at the time can connect to ETHM-1.
If yes, try to disconnect ETHM-1 from the network by pulling out the wire or power cycling the module.

I hope it will help.

216

Hello druciak

Would you kindly look at the issue described in my post: https://community.openhab.org/t/satel-integra-64-can-not-connect-to-int-rs/104497 :slightly_smiling_face:
The doc states that satel binding shall work with INT-RS/INT-RS Plus but I have an impression that it does not work with INT-RS

In this thread above I have found similar issue of repetitive disconnecting related to ETHM-1, for which you have implemented some fix. I an wondering if this would be possible for INT-RS or it is not longer supported?

217

Hi RafaƂ,
thanks for the info, I sometimes search the community for keyword “satel”, but the best idea is to post any issues here, or at least mention me in the post, so I get a notification.

The main problem with INT-RS is that I don’t own any, but there was somebody with this module in the past and we managed to get the binding working with his module. This was some time ago and I have no idea if it still works, but I hope it does.
However from your log in the other thread it seems the module does not respond to 7E command at all. According to the documentation the latest INT-RS version is 1.14, you mentioned 1.4, maybe this is the problem. Also you have additional hardware (a converter) between the module and your OH machine, are you sure it works? Did you test it somehow?
I will try to help you, but it is really hard to find the issue remotely. Anyway I am happy to help.

218

It is good idea to tag topics with satel tag to which everyone can subscribe. :wink:

1 Like
219

Thank you for response. I think I have made mistake and the version of INT-RS was 1.14. This seems to be the last version before INT-RS Plus. I am now away but next week shall be back to check it and try to find some test for converter I have put together. Will let you know!

220

I am back at investigation :wink:

I have INT-RS version v 1.14 2016-03-09. It seems to be last available version of the firmware before the next one released for INT-RS Plus (v2.18 2018-01-11)

I have checked my RS232-USB converter using loop-back test and in both windows and Linux it works (I can see echo using puTTY and both RX and TX LEDs are flashing)
When attached to OpenHab I have noticed that the TX LED of the converter flashes from time to time which seems to be “trying to connect”/sending signal from Satel binding/Openhab? But no response from Satel INT-RS :frowning:

Also I have set up another converter translating RS 232 to Wifi/Ethernet (Max2323 + ESP8266).
But after connecting (via ETHM-1 binding) I have similar messages: opening and closing connection.

I can not find any options in DloadX related to INT-RS setup. Seems it shall work out of the box (and it works currently with my PLC using Modbus RTU protocol)

Hence, I am close to conclude that the binding does not support INT-RS. You have mantioned about smb from the forum using INT-RS not sure if was not INT-RS Plus?

221

If you are sure your converter works properly, we can move forward to the next step :slight_smile:
Please make sure you have configured your INT-RS to work using integration protocol (Function 2) as described in Integration Protocol doc (available on Satel web site).

222

Protocol of satel (Funcion 2) specifies as follows:
RS-232 serial port of INT-RS module is configured as 19200/8/1/N. The DB9 connector uses the same lines as in Function 1.

I asume the above is already included in the satel binding?
In my PLC program (which comminicates with INT-RS) I have similar setting:
fbBX_COM_64.ComConfig.eCommPort := COM2; (* Bridge between PIN 7-8 X01, only RS232 *)
fbBX_COM_64.ComConfig.BaudRate := 19200;
fbBX_COM_64.ComConfig.eDataBits := EIGHT_DATABITS;
fbBX_COM_64.ComConfig.eStoppBits := ONE_STOPPBIT;
fbBX_COM_64.ComConfig.eParity := NONE;

And 3 lines of DB9 connector are used for communication:

  • RX (pin 2) - serial input
  • TX (pin 3) - serial output
  • GND (pin 5) - signal ground
223

You can find relevant code here.

On PLC, did you communicate with INT-RS using integration protocol? I am just making sure all (i.e. dip switches) is configured on the module side properly to work with integration protocol (Function 2).

224

@druciak thanks for hint. OH and Satel restart/power cycle helped indeed :slight_smile:

225

I have checked the DIP-switch 8
4 is 0010 (5 is ON) which means Function 2 (integration protocol). I am not the author of the PLC program which communicates with Satel and not easy for me to understand it. In fact I am only reading data of Satel in my PLC but I think the program in every PLC cycle calls some SerialLineControl function to receive the data.

226

Send me a PM, let’s discuss further steps offline.

227

I have managed to find the issue :grinning: The firmware in INT-RS was not upgraded to 1.14 while I was trying to do it via Integra 64 central.
In order to upgrade it you need to connect directly to INT-RS module via its DB9 socet!

228

After resolving the firmware issue, the discovery of satel binding works fine and all may Satel`s zones, partitions and others were identified😊. I am progressing with items and things definition


But I have noticed a difference to my current set-up in OH2 integrated with satel via PLC/modbus: Why zones in satel binding are presented as switch items and not as contact items?

If I understand correctly we shall read state of zones from satel and not set them up in the OH2?

Also there are quite nice dynamic icons in OH2 for contact items including: <motion> for PIR sensor attached to satel and <door> / <windows> for reed switch (attached to satel)

Is it possible to change zone items from Switch type to Contact type? For example channel violation of the Zone thing to be a contact type?

229

Main reason is: because it was easier for me to implement the binding that way. Zone things have many channels and I wasn’t sure which of them should be contact, and for which of them a switch would be better. For some of them you can send commands (BYBASS), some of them obviously should be contact (VIOLATION), but the rest isn’t so obvious, so I decided to use switch type for all of them. That maybe wasn’t a good decision, but now it is not easy to change it.
Besides OH is very flexible and you can achieve whatever you want in many ways. You can for example rename icons (or copy to new files) door-open.png to door-on.png and voilĂ , you have dynamic icon for doors. :wink:

230

Thank you for your hint regarding dynamic icons. In addition I have changed Switch item type into String type on site map so there are no switches for violation items😊
New questions and observations:

  1. What is the difference between Armed channel and Really Armed channel in Partition thing?

  2. When I am setting Armed in OH2 (using Armed channel) and I have a blocked or violated zone ( ex open window) the satel is arming despite that Force Arming option in Partition thing is off.

  3. When I am setting Armed in OH2 for partition with a given time to leave option in Satel(ex 30 sec) the thing changes back into Disarmed then after ~30esc it changes into Armed, as follows:

2020-10-05 21:10:43.692 [ome.event.ItemCommandEvent] - Item 'Satel_PARTITION_1_ARMED' received command ON
2020-10-05 21:10:43.710 [nt.ItemStatePredictedEvent] - Satel_PARTITION_1_ARMED predicted to become ON
2020-10-05 21:10:43.758 [vent.ItemStateChangedEvent] - Satel_PARTITION_1_ARMED changed from OFF to ON
2020-10-05 21:10:45.420 [vent.ItemStateChangedEvent] - Satel_PARTITION_1_ARMED changed from ON to OFF
2020-10-05 21:11:14.171 [vent.ItemStateChangedEvent] - Satel_PARTITION_1_ARMED changed from OFF to ON