Domoticz

Hi Fantom,

Great job !!

Will this work with the Satel Versa plus panel with integrated ethernet ?

Thanks

I dont't know
You must check this.
I don't know whts exists inside this versa board.

Fantom

Hi!

Great job fantom... your software is great. I didn't think that Satel could act this fantastic way with Domoticz!

But... Most probably I found a bug in your code. I cannot constantly read output #20 from my Integra WRL due to some CRC issues. Because I have eaten my teeth writing intelligent inmate's presence using Perl script, I tried to read your code (but I have only basic knowledge of C).

Here is frame sent from Domoticz towards ETHM-1 (just the faulty scenario): Extracted request: And Domoticz receives following back: Extracted response: And here, simple xFE of CRC was "escaped" by xF0. From your code I can see that "escape" characters are removed from message (that's ok), but not from CRC part:
Of course I can be wrong, as I didn't understand in 100% this part of code yet, but I'm working on this and try to help here.

======Added 23:52:

I turned on some "debug features" adding two lines: and output I received:
(Good output) (Bad output) It seems for me that because of single xFE as first CRC byte it's replaced by "xFE xF0" and "xFE" is included to CRC (instead of "xF0") and "xFE" is wrongly appended to answer variable. May I advice you to clean the "answer" just when it came by replacing "xFE xF0" by single "xFE"?

P.S.: Please don't get me wrong... I'm sure I'm not able to write this amount of excellent code, as you did

@smurphy:
Fantom's method uses "Integration protocol" which is implemented on ETHM-1 and Plus (newer version) and INT-RS (and Plus) and supported only by Integer's main boards. And his code is written for ETHM version s only (not RS). So... I'm sorry, it will not speak to Versa at all.

Hu.
I know that error, and I already wrote once about it.
But my knowledge of C++ is also so bad, that I can not seem to get on to improve
I wrote it myself some time ago and I will try to somehow fix it.
Or maybe you know how to do it easy ?

Fantom

Fantom,

It seems I have a patch. Let me test it for few hours.

ok. i started fixing it, but ... no more times today. Maybe in weekend.

Fantom

Sory to post it here, but I'm newbie here and not able to send PM.

Below simple code fixed CRC errors for me. It simply look at every array element of "buffer". If "xFE xF0" found, then "xF0" is dropped from "buffer" and next elements are moved left. Last step is to clear last "buffer" element and decrease array size ("ret"). I've put this fixing part between initialization of "ret" (line 1086) and check size of "ret" var.
The last thing I've changed was to remove following line: ... just to speedup a liitlebit.

Now I know I need to lear how to prepare patches in required format.
... and patch attached:

I'm not good in c++, but i see first bug : loop is not working properly when i=0 (first pass)

Fantom

Yeah, right... I missed this.

It would cause a read of different memory range, which not belong to "buffer". I assume it will not be a common case when some other var will be equeal xFE, but even if someone will pass this test, then test for xF0 will be failed still because standard frame in buffer looks like:
I opt to change initial value of "i" in for loop to 1, so:

Hi

I consider to buy SATEL ETHM-1 and I have questions about integration Integra with domoticz.
Is it possible in domoticz to read status of outs and turn on/off mono or bistable out on Integra?

BR

Hi plmisiek,

For following output types you can read their current status and turn them on/off/toggle (as it was wrote by fantom on page 4th of this thread):
1) 24 switch MONO
2) 25 switch BI
3) 105 roller blind up
4) 106 roller blind down
5) >= 64 and <= 79 DTMF

You will be also allowed to receive input status.

Just please keep in mind that Integra will be asked for current statuses once per 2 seconds (or 1 second). So in case if something (input or output) will change it's status to on and off during this short period of time, Domoticz may not catch this. It will work correctly for most Sate PIR sensors (for example), but if you plan to use INT-E input expanders for wall switch (monostable - bell type) an short impulse from them can be not captured by Domoticz. For me, default 320 ms signal length in Satel was not enough to switch the light using those wall switches (so I decreased time below 50 ms, and is OK now).

Hi Grucha,

Thank you for clarification.
I use monostable wall switch and 100ms is ok for me, 320ms was to high value.
Have you tried to use GuardX connected by RS232 and domoticz connected by ETHM-1 at the same time?

Pozdr.

No, I didn't.
Do you have INT-RS also for GuardX or you plan to use RS232 on main board? Please keep in mind if you plan to use RS232 socket on the board for GuardX, then no programming functionality be possible over ETHM-1.

In my opinion better is to run GuardX over TCP. It should be possible at the same time with "integration" connecton - this from Domoticz. I'm not sure if for GuardX it's possible, but I am able to connect from DloadX to Satel thru ETHM-1 in the same time when Domoticz is connected.

Hi Fantom, thanks for the great work on this module so far!

Question; I have created a LUA Script in Domoticz which switches on a light in case movement is detected by a Satel ZONE (PIR).
However I see that when the PIR is triggered, it takes some time before I see this in Domoticz - so this means:

PIR detects movement, zone change on Satel keypad is shown instantly, but there's a delay (up to 30-60 seconds) before the status is seen in Domotiz log and - as result of the LUA script - light is switched on.

Is there any option to set the interval to a shorter timeframe for pulling or pushing (don't know what method is used), to allow Domoticz 'seeing' a status change of a Satel ZONE quicker?

Thanks

This is very strange.
I read data from Integra every 2 or 3 sec.
Maybe set more logs and check what happens

Fantom

@grucha - I created a quick fix for crc calculating :
https://github.com/domoticz/domoticz/co ... 9a2fc9bc72
Lets waiting on merge and will test it.

Fantom
ps. Are you from Poland ?

pmmisiek wrote:Hi Grucha,

Thank you for clarification.
I use monostable wall switch and 100ms is ok for me, 320ms was to high value.
Have you tried to use GuardX connected by RS232 and domoticz connected by ETHM-1 at the same time?

Pozdr.

You can use virtual output - trigerred from zone. And you may set time for this output for example to 10 sec.

Fantom

Fantom,
Thanks for this fix. I'm glad that you raised this to main branch. it has been added already by gizmocuz.

[Jasne. Z okolic Bydgoszczy ]

@grucha:

Thanks for the info. Maybe in the future.
Versa plus looks like a nice panel.

grucha wrote:Hi!

Great job fantom... your software is great. I didn't think that Satel could act this fantastic way with Domoticz!

But... Most probably I found a bug in your code. I cannot constantly read output #20 from my Integra WRL due to some CRC issues. Because I have eaten my teeth writing intelligent inmate's presence using Perl script, I tried to read your code (but I have only basic knowledge of C).

Here is frame sent from Domoticz towards ETHM-1 (just the faulty scenario):

Code: Select all

22:03:43.689943 IP (tos 0x0, ttl 64, id 63072, offset 0, flags [DF], proto TCP (6), length 49)
    10.0.1.3.40920 > 10.0.1.2.http-alt: Flags [P.], cksum 0x457a (correct), seq 2470209130:2470209139, ack 36715416, win 14600, length 9
	0x0000:  4500 0031 f660 4000 4006 2e62 0a00 0103  E..1.`@[email protected]....
	0x0010:  0a00 0102 9fd8 1f90 933c 666a 0230 3b98  .........<fj.0;.
	0x0020:  5018 3908 457a 0000 fefe ee04 1463 15fe  P.9.Ez.......c..
	0x0030:  0d

Extracted request:

Code: Select all

ee04 1463 15

And Domoticz receives following back:

Code: Select all

10.0.1.2.http-alt > 10.0.1.3.40920: Flags [P.], cksum 0xd1eb (correct), seq 36715416:36715443, ack 2470209139, win 6144, length 27
	0x0000:  4500 0043 8c75 0000 ff06 193b 0a00 0102  E..C.u.....;....
	0x0010:  0a00 0103 1f90 9fd8 0230 3b98 933c 6673  .........0;..<fs
	0x0020:  5018 1800 d1eb 0000 fefe ee04 1419 4f73  P.............Os
	0x0030:  7720 7072 7a65 6473 696f 6e65 6b20 fef0  w.przedsionek...
	0x0040:  52fe 0d                                  R..

Extracted response:

Code: Select all

ee04 1419 4f73 7720 7072 7a65 6473 696f 6e65 6b20 fef0 52

And here, simple xFE of CRC was "escaped" by xF0. From your code I can see that "escape" characters are removed from message (that's ok), but not from CRC part:

Code: Select all

1093                         for (int i = 0; i < ret - 6; i++)
   1094                                 if (buffer[i + 2] != 0xF0 || buffer[i + 1] != 0xFE) // skip special value
   1095                                 {
   1096                                         answer[answerLength] = buffer[i + 2];
   1097                                         answerLength++;
   1098                                 }

Of course I can be wrong, as I didn't understand in 100% this part of code yet, but I'm working on this and try to help here.

======Added 23:52:

I turned on some "debug features" adding two lines:

Code: Select all

1093                         for (int i = 0; i < ret - 6; i++)
   1094                                 if (buffer[i + 2] != 0xF0 || buffer[i + 1] != 0xFE) // skip special value
   1095                                 {
   1096                                         answer[answerLength] = buffer[i + 2];
   1097                                         answerLength++;
   1098                                 }
   1099         _log.Log(LOG_STATUS, "Received frame(crc): %x %x", buffer[ret-4],buffer[ret-3]); //--------Here
   1100                         unsigned short crc;
   1101                         calculateCRC(answer, answerLength, crc);
   1102         _log.Log(LOG_STATUS, "Received answer for output: %x CRC: %x", answer, crc);//--------Here
   1103                         if ((crc & 0xFF) == buffer[ret - 3] && (crc >> 8) == buffer[ret - 4])

and output I received:
(Good output)

Code: Select all

2015-11-09 23:38:23.193  Received frame(crc): e5 7e
2015-11-09 23:38:23.194  Received answer for output: b478a218 CRC: e57e
2015-11-09 23:38:23.195  (Integra) Light/Switch (Output:Osw gabinet)

(Bad output)

Code: Select all

2015-11-09 23:38:23.714  Received frame (crc): f0 52
2015-11-09 23:38:23.714  Received answer for output: b478a218 CRC: 45b
2015-11-09 23:38:23.715  Error: Satel Integra: receive bad CRC
2015-11-09 23:38:23.715  Error: Satel Integra: Receive info about output 19 failed

It seems for me that because of single xFE as first CRC byte it's replaced by "xFE xF0" and "xFE" is included to CRC (instead of "xF0") and "xFE" is wrongly appended to answer variable. May I advice you to clean the "answer" just when it came by replacing "xFE xF0" by single "xFE"?

P.S.: Please don't get me wrong... I'm sure I'm not able to write this amount of excellent code, as you did

@smurphy:
Fantom's method uses "Integration protocol" which is implemented on ETHM-1 and Plus (newer version) and INT-RS (and Plus) and supported only by Integer's main boards. And his code is written for ETHM version s only (not RS). So... I'm sorry, it will not speak to Versa at all.

grucha wrote:Fantom,
Thanks for this fix. I'm glad that you raised this to main branch. it has been added already by gizmocuz.

[Jasne. Z okolic Bydgoszczy ]

Yes. It is merged. Now i waiting for new versjion

Fantom