[FHZ] Can't get M232 to work at NSLU serial port

Begonnen von Guest, 03 November 2009, 13:53:24

Vorheriges Thema - Nächstes Thema

Guest

Originally posted by: <email address deleted>

Hi, hopefully somebody can help me with this:

trying to set up a M232 device connected to the internal serial port
of the NLSU. Always get read errors when using set or get.

The serial port works fine, could log on to Linux with a PC as
terminal.

Tested the M232 with self-made adapter cable and the software that
came with it at a PC, worked fine (only when booted to DOS prompt,
though)

Also tested the port with FHEM with the PC terminal. Could receive the
commands sent, but got the same read error from FHEM.

Any ideas what could be the cause for this?

Thanks

LB_ORL

I
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

Dr. Boris Neubert

                                             

Hi,

LB_ORL schrieb:
> Any ideas what could be the cause for this?
>
>  
could you please start fhem with a minimal configuration and maximum
verbosity on the NSLU and post the logs?

Regards,
Boris


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Guest

Originally posted by: <email address deleted>

On 3 Nov., 16:57, "Dr. Boris Neubert" wrote:
> Hi,
>
> LB_ORL schrieb:> Any ideas what could be the cause for this?
>
> could you please start fhem with a minimal configuration and maximum
> verbosity on the NSLU and post the logs?
>
> Regards,
> Boris

Thanks for the response. Here is the my last telnet session including
the log:

www-data@fhz:/usr/local/bin$ telnet localhost 7072
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

FHZ> get m232 octet
Read error
FHZ> quit
Bye...
Connection closed by foreign host.
www-data@fhz:/usr/local/bin$ cat /tmp/fhem.log
2009.11.03 23:43:52 5: Cmd: >define m232 M232 /dev/COM1<
2009.11.03 23:43:52 5: Loading /usr/local/lib/FHEM/80_M232.pm, order
80
2009.11.03 23:43:52 3: M232 opening device /dev/COM1
2009.11.03 23:43:53 3: M232 opened device /dev/COM1
2009.11.03 23:43:53 0: Server started (version =VERS= from =DATE=
($Id:
fhem.pl,
v 1.80 2009/09/11 07:34:12 rudolfkoenig Exp $), pid 13533)
2009.11.03 23:44:04 4: Connection accepted from 127.0.0.1:3661
2009.11.03 23:44:17 4: Connection accepted from 127.0.0.1:3662
2009.11.03 23:44:17 5: Cmd: >xmllist<
2009.11.03 23:44:17 5: Cmd: ><
2009.11.03 23:44:18 5: Cmd: >quit<
2009.11.03 23:44:18 4: Connection closed for 127.0.0.1:3662
2009.11.03 23:45:20 5: Cmd: >set m232 io1 1<
2009.11.03 23:45:20 4: M232: Sending D11
2009.11.03 23:45:22 4: M232: ?
2009.11.03 23:45:26 5: Cmd: >quit<
2009.11.03 23:45:26 4: Connection closed for 127.0.0.1:3661
2009.11.03 23:46:28 4: Connection accepted from 127.0.0.1:3985
2009.11.03 23:46:28 5: Cmd: >xmllist<
2009.11.03 23:46:28 5: Cmd: ><
2009.11.03 23:46:28 5: Cmd: >quit<
2009.11.03 23:46:28 4: Connection closed for 127.0.0.1:3985
2009.11.03 23:49:33 4: Connection accepted from 127.0.0.1:3986
2009.11.03 23:49:33 5: Cmd: >xmllist<
2009.11.03 23:49:33 5: Cmd: ><
2009.11.03 23:49:33 5: Cmd: >quit<
2009.11.03 23:49:33 4: Connection closed for 127.0.0.1:3986
2009.11.03 23:52:39 4: Connection accepted from 127.0.0.1:4087
2009.11.03 23:52:39 5: Cmd: >xmllist<
2009.11.03 23:52:39 5: Cmd: ><
2009.11.03 23:52:39 5: Cmd: >quit<
2009.11.03 23:52:39 4: Connection closed for 127.0.0.1:4087
2009.11.03 23:53:08 4: Connection accepted from 127.0.0.1:4088
2009.11.03 23:53:54 5: Cmd: >set m232<
2009.11.03 23:54:00 5: Cmd: >get m232 octet<
2009.11.03 23:54:00 4: M232: Sending w
2009.11.03 23:54:02 4: M232: ?
2009.11.03 23:54:06 5: Cmd: >quit<
2009.11.03 23:54:06 4: Connection closed for 127.0.0.1:4088
2009.11.03 23:55:44 4: Connection accepted from 127.0.0.1:4089
2009.11.03 23:55:44 5: Cmd: >xmllist<
2009.11.03 23:55:44 5: Cmd: ><
2009.11.03 23:55:44 5: Cmd: >quit<
2009.11.03 23:55:44 4: Connection closed for 127.0.0.1:4089
2009.11.03 23:58:22 4: Connection accepted from 127.0.0.1:4742
2009.11.03 23:58:29 5: Cmd: >get m232 octet<
2009.11.03 23:58:29 4: M232: Sending w
2009.11.03 23:58:31 4: M232: ?
2009.11.03 23:58:35 5: Cmd: >quit<
2009.11.03 23:58:35 4: Connection closed for 127.0.0.1:4742
www-data@fhz:/usr/local/bin$

Regards,

LB_ORL

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

Dr. Boris Neubert

                                             

Hi,

LB_ORL schrieb:
> 2009.11.03 23:45:20 5: Cmd: >set m232 io1 1<
> 2009.11.03 23:45:20 4: M232: Sending D11
> 2009.11.03 23:45:22 4: M232: ?
>  
this occurs at FHEM/80_M232.pm in sub M232GetData(). The return value is
the default value set in line 289. I cannot see from the code how this
might happen. Could you please add additional Log commands in the
mentioned module to see where and why the subroutine bails out?

Regards,
Boris


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

rudolfkoenig

Originally posted by: <email address deleted>

Hi,

yesterday evening, FHEM (4.7) lost my CUN:

[...]
2009.11.03 19:36:06 2: FHZ get FHZ1 serial
[...]
2009.11.03 19:36:06 3: FHZ1 serial => ********
2009.11.03 19:36:06 5: redefine at command at_get_serial as +*00:05 { \
2009.11.03 19:36:06 5: exec at command at_get_CUN_version
2009.11.03 19:36:06 5: Cmd: >{ \
2009.11.03 19:36:06 5: Cmd: >get CUL2 version<
2009.11.03 19:36:06 3: CUL2 version => No answer
2009.11.03 19:36:06 5: redefine at command at_get_CUN_version as +*00:01 { \
2009.11.03 19:38:03 5: Cmd: >define CUL2 CUL 000.00.000.00:2323 3e06<
2009.11.03 19:38:03 5: Loading /usr/local/lib/FHEM/00_CUL.pm, order 00
2009.11.03 19:38:03 3: CUL opening CUL device 000.00.000.00:2323
2009.11.03 19:38:04 3: CUL opened 000.00.000.00:2323 for CUL2
2009.11.03 19:38:07 1: Cannot init 000.00.000.00:2323, ignoring it
2009.11.03 19:38:07 3: CUL2: Timeout reading answer for get Version
2009.11.03 19:38:07 5: Cmd: >attr CUL2 loglevel 3<
2009.11.03 19:38:07 3: Please define CUL2 first
2009.11.03 19:38:07 5: Cmd: >attr CUL2 model CUL<
2009.11.03 19:38:07 3: Please define CUL2 first
2009.11.03 19:38:07 3: CUL opening CUL device /dev/busware_cul
2009.11.03 19:38:07 3: CUL opened /dev/busware_cul for CUL1
2009.11.03 19:38:07 5: CUL/RAW: K1133524707
2009.11.03 19:38:07 5: CUL/RAW: V 1.30 CUL868
2009.11.03 19:38:07 5: CUL/RAW: 3E06
2009.11.03 19:38:07 5: GOT CUL fhtid: 3E06
2009.11.03 19:38:07 5: Cmd: >attr CUL1 loglevel 3<
2009.11.03 19:38:07 5: Cmd: >attr CUL1 model CUL<
[...]

I'm not sure why there was a problem talking to the CUN nor why 00_CUL.pm
was re-read. What can be done to have FHEM handle temporary outages more
gracefully? Usually FHEM copes well with CUN (or a socat-connected CUL)
not being there, the "get CUL2 version" restarts communication with CUN after
e. g. a reboot of CUN on a regular basis.

But this time, CUN did now reboot:

FHZ> get CUL2 raw t
CUL2 raw => 031BAAFE

=> 0x31B8264/0x7D/0x1518 ~ 4.828 days of CUN operation, if I'm not mistaken

Any tips on how to prevent this from happening again are greatly appreciated,
         kai

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

Dirk

                                                   

> 2009.11.03 19:36:06 3: FHZ1 serial => ********
As I wrote it in different postings: Using an FHZ, a CUL with fhtid != 0000 and
FHT's will cause communication problems with the FHT's


> 2009.11.03 19:38:03 5: Cmd: >define CUL2 CUL 000.00.000.00:2323 3e06<
Is this really 000.00.000.00 ?


> 2009.11.03 19:38:03 5: Loading /usr/local/lib/FHEM/00_CUL.pm, order 00
This is a bug. To identify the problem I need your whole logfile, your
configuration file and the listing of the FHEM directory.


> FHZ> get CUL2 raw t
> CUL2 raw => 031BAAFE
??? The log above told me that you have no connection to CUL2.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

rudolfkoenig

Originally posted by: <email address deleted>

Rudolf Koenig wrote:
>> 2009.11.03 19:36:06 3: FHZ1 serial => ********
> As I wrote it in different postings: Using an FHZ, a CUL with fhtid != 0000 and
> FHT's will cause communication problems with the FHT's

FHZ can't reach reliably the FHT in question, so there's no way around
this setup for now. Using different fhtids for FHZ and CUL(s) is ok?

>> 2009.11.03 19:38:03 5: Cmd: >define CUL2 CUL 000.00.000.00:2323 3e06<
> Is this really 000.00.000.00 ?

Of course not. But it's a routed address, reachable from the Internet,
therefore I obfuscated it for posting this publicly.

>> 2009.11.03 19:38:03 5: Loading /usr/local/lib/FHEM/00_CUL.pm, order 00
> This is a bug. To identify the problem I need your whole logfile, your
> configuration file and the listing of the FHEM directory.

Ok, will send it directly.


>> FHZ> get CUL2 raw t
>> CUL2 raw => 031BAAFE
> ??? The log above told me that you have no connection to CUL2.

Sorry, I thought that would be obvious: after noticing the loss of CUL2
(responsible for 1 EM, 1 FHT, 2 HMS, 1 WS) this morning, I stopped and
restarted FHEM, then I checked CUN's uptime. While I do have an ps|grep-
based automated FHEM restart in place, I'm at loss right now how to cope
with a running FHEM process that's lacking sensors. As FHEM is not pro-
ductive currently (beyond T/H-measurement and timing the lights of the
terrarium), that's no big issue, yet.

Regards,
         kai


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

rudolfkoenig

                                                   

> Using different fhtids for FHZ and CUL(s) is ok?

I put it the other way round: Using the same fhtid for the FHZ and the CUL is
even worse :)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

rudolfkoenig

Originally posted by: <email address deleted>

Just to be sure I understood the issue correctly, is the following true?

- When an FHT-80b sends out messages like measured-temp, it won't send
the code of the CUx/FHZ it wants to send the message to, but only its
own code to mark the origin of the message.
- These messages are bidirectional, there are several telegrams going
to and fro between the CUx/FHZ and FHT-80b until the message is
"through".
- The CUx devices will send answers to every telegram they receive,
regardless of whether the sending FHT-80b is paired with them or with
other CUx/FHZ devices.
- If the FHT-80b is already paired with another CUx/FHZ, it will
ignore the answers from the CUx as they don't contain the correct
housecode.
- If the radio reception is not good between the non-paired CUx and
the FHT-80b, the CUx might miss some of the telegrams sent to the
actually paired CUx/FHZ device.
- It will then conclude that its last telegram has not been received
and try forever to send it out. As the adressed FHT-80b is paired with
another CUx/FHZ, it will ignore these telegrams.

If this is true, more questions:

1. Will the CUx's connection to other FHT80bs be disturbed by that? In
other words, will it try to complete the dialog with the "wrong"
FHT-80b before it sends anything to other FHT-80bs?
2. Will the FHT buffer overflow at some point or does the CUx detect
that the FHT-80b in question is already sending another message, so
its previous answer can be taken out of the buffer? (Is taking sth out
of the buffer possible at all, as it is probably just a char buffer,
and it is unknown which message is at which offset?)
3. How do FHZ devices handle this?

Thank you,

Christian

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

rudolfkoenig

                                                   

> - When an FHT-80b sends out messages like measured-temp, it won't send
> the code of the CUx/FHZ it wants to send the message to, but only its
> own code to mark the origin of the message.

The first (FHT_START_XMIT) telegram contains the one byte code of the
associated FHZ, the rest not. All telegrams contain the FHT id.

If the CUL receives an FHT telegram with the code of a foreign FHZ, then it
won't reply to the rest of the telegrams (in this slot). But if it misses
this message, then it automatically ack's the rest. The other way round (ack
only if I got my own FHZ code) would be better.


> - It will then conclude that its last telegram has not been received
> and try forever to send it out. As the adressed FHT-80b is paired with
> another CUx/FHZ, it will ignore these telegrams.

For the CUL forever == 2 times. The FHT won't really know who is the sender
(that is, for message number 2+), but both CUL's/FHZ's will reply at the same
time, disturbing each other.  The FHT will stop and start sending the data in
the next timeslot, 115+x seconds later.


> 1. Will the CUx's connection to other FHT80bs be disturbed by that? In
> other words, will it try to complete the dialog with the "wrong"
> FHT-80b before it sends anything to other FHT-80bs?

No, as a telegram is repeated only twice


> 2. Will the FHT buffer overflow at some point or does the CUx detect
> that the FHT-80b in question is already sending another message, so
> its previous answer can be taken out of the buffer? (Is taking sth out
> of the buffer possible at all, as it is probably just a char buffer,
> and it is unknown which message is at which offset?)

The CUL removes an FHT telegram from its buffer after it received the last ack
from the FHT for the whole message. If the FHT is not associated with the CUL,
it won't even reply to the initial start telegram.
-> Do not send commands to FHT's associated to a different FHZ/CUL, as only a
   reset (or T01HHHH) will remove these commands from the CUL buffer.


> 3. How do FHZ devices handle this?

Show me the source and I will tell you :)


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

Guest

Originally posted by: <email address deleted>

Moin,

ich habe einen FHT80TF (aus einem FHT80B-Set) aktiviert, ich schätze mal,
folgendes ist die Willkommensnachricht?

2009.11.05 22:44:20 5: CUL/RAW: /T965AB00CE1

2009.11.05 22:44:20 3: CUL1: T965AB00C -89.5
2009.11.05 22:44:20 3: CUL: unknown message T965AB00C
2009.11.05 22:44:20 5: CUL/RAW: /T965AB00C4C

2009.11.05 22:44:20 3: CUL2: T965AB00C -36
2009.11.05 22:44:20 3: CUL: unknown message T965AB00C

Wenn ich den Magneten vom Reed-Kontakt weg- und wieder hin bewege, macht
die LED des FHT80TF etwas ("auf": kurzes Aufleuchten, "zu": langes Auf-
leuchten), CUL (oder FHZ) empfangen dann allerdings offensichtlich nichts.
Dafür tauchen nun diese Einträge immer wieder auf:

2009.11.05 23:04:41 5: CUL/RAW: /T965AB001E1

2009.11.05 23:04:41 3: CUL1: T965AB001 -89.5
2009.11.05 23:04:41 3: CUL: unknown message T965AB001
2009.11.05 23:04:42 5: CUL/RAW: /T965AB00149

2009.11.05 23:04:42 3: CUL2: T965AB001 -37.5
2009.11.05 23:04:42 3: CUL: unknown message T965AB001
2009.11.05 23:04:42 5: CUL/RAW: /T965AB081E1

2009.11.05 23:04:42 3: CUL1: T965AB081 -89.5
2009.11.05 23:04:42 3: CUL: unknown message T965AB081
2009.11.05 23:04:42 5: CUL/RAW: /T965AB08149

2009.11.05 23:04:42 3: CUL2: T965AB081 -37.5
2009.11.05 23:04:42 3: CUL: unknown message T965AB081

FHEM kennt derzeit das "FHT80TF-Protokoll" nicht, oder? Schade, ich würde
gerne die Türen-/Fensterkontakte auch außerhalb der FHT-internen Steuerung
nutzen. Gibt's Alternativen? "FS20 TFK" scheint die "Standalone-Variante"
zu sein, hat die einen anderen, FHEM bekannten, Code?

MfG,
         kai

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

rudolfkoenig

                                                   

Hallo Kai,

kannst Du bitte folgendes Pruefen und uns mitteilen:
- wie oft/haeufig kommt T965AB00C
- wann genau kommt      T965AB001
- wann genau kommt      T965AB081

Mit diesen Infos kann man ein Modul bauen (siehe 09_BS.pm).

Meines Wissens nach meldet der FHZ den 80TF nicht direkt, diese Daten kommen
ueber den FHT80b (warnings: Window open).

Gruss,
  Rudi

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

rudolfkoenig

Originally posted by: <email address deleted>

On 4 Nov., 19:53, "Dr. Boris Neubert" wrote:
> Hi,
>
> LB_ORL schrieb:> 2009.11.03 23:45:20 5: Cmd: >set m232 io1 1<
> > 2009.11.03 23:45:20 4: M232: Sending D11
> > 2009.11.03 23:45:22 4: M232: ?
>
> this occurs at FHEM/80_M232.pm in sub M232GetData(). The return value is
> the default value set in line 289. I cannot see from the code how this
> might happen. Could you please add additional Log commands in the
> mentioned module to see where and why the subroutine bails out?
>
> Regards,
> Boris

OK, I am still struggling with Perl, but finally I succeeded in adding
some lines:

 for(;;) {
    if ($^O eq 'MSWin32') {
      $nfound=M232_Ready($hash,undef);
    }else{
      my ($rout, $rin) = ('', '');
my $FN = $serport->FILENO;
      vec($rin, $serport->FILENO, 1) = 1;
my $RI = unpack("b*",$rin);
    $nfound = select($rin, undef, undef, 1.0); # 3 seconds timeout
Log 4, "nfound:  $nfound FN: $FN rin: $RI";
      if($nfound < 0) {
        next if ($! == EAGAIN() || $! == EINTR() || $! == 0);
        $rm="M232:Select error $nfound / $!";
        last;
      }
    }

      last if($nfound == 0);



Now the log looks like this:

2009.11.06 01:14:42 5: Cmd: >get m232 octet<
2009.11.06 01:14:42 4: M232: Sending w
2009.11.06 01:14:53 4: nfound:  0 FN: 6 rin: 00000010
2009.11.06 01:14:53 4: M232: ?
2009.11.06 01:15:08 5: Cmd: >quit<
2009.11.06 01:15:08 4: Connection closed for 127.0.0.1:3343


I appreciate your helping me with this.

Regards,

LB_ORL

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

Guest

Originally posted by: <email address deleted>

Thanks for the clarifications.

2009/11/5 Rudolf Koenig :
> If the CUL receives an FHT telegram with the code of a foreign FHZ, then it
> won't reply to the rest of the telegrams (in this slot). But if it misses
> this message, then it automatically ack's the rest. The other way round (ack
> only if I got my own FHZ code) would be better.

>> 3. How do FHZ devices handle this?
>
> Show me the source and I will tell you :)

:-) I meant the behaviour that can be observed, i.e. when do FHZs send
telegrams and when not.

Most problematic cases I thought were there in fact are not, so it's
all in all not as big a problem as I thought, anyway. Only the case
above remains, so: Do FHZs ack messages where they missed they
start-xmit telegram? (I can't try to find that out myself as I don't
own one.)

Best regards,

Christian

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

JuergenL

                                               

Hallo Kai,

On Nov 5, 11:21 pm, Kai 'wusel' Siering
wrote:
> Wenn ich den Magneten vom Reed-Kontakt weg- und wieder hin bewege, macht
> die LED des FHT80TF etwas ("auf": kurzes Aufleuchten, "zu": langes Auf-
> leuchten),

Meine älteren FHT80TFs blinken 3 mal kurz beim Schließen (Reedkontakt
geschlossen) und einmal lang beim Öffnen.
Hast Du das neuere Gerät im kleinen Gehäuse?

> FHEM kennt derzeit das "FHT80TF-Protokoll" nicht, oder? Schade, ich würde
> gerne die Türen-/Fensterkontakte auch außerhalb der FHT-internen Steuerung
> nutzen. Gibt's Alternativen? "FS20 TFK" scheint die "Standalone-Variante"
> zu sein, hat die einen anderen, FHEM bekannten, Code?

IMHO macht das FS20TFK einfache FS20-Schaltbefehle (ich habe mal
"versehentlich" einen gekauft und hier rumliegen).
Damit kommt FHEM bekannterweise gut klar.


Gruß,
Jürgen
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-