HomeMatic und HMLAN: Sender bekommen keine Antwort

[Guest]

Originally posted by: <email address deleted>

Hallo Eppi,

Seit einiger Zeit (weiss leider nicht mehr genau wann), bekomme ich
> ebenfalls kein grünes LED mehr zu sehen an meinem Fensterkontakt-SC wenn
> das Fenster auf/zu geht. Ich habe gestern probiert die Kontakt neu zu
> pairen mit hmPairForSec 600, was auch prima geklappt hat.
>
damit hast du den Schalter an der Zentrale gepairt. Das ist kein peer -
sondern die Zentrale. Hier lag sicher auch nicht das Problem.
Das Problem der roten Lampe sollte kommen, wenn der schalter einen peer
(gleichgestellen - also aktor) eingetragen hat und nach dem Schalten keine
Rueckmeldung -vom Peer- bekommt.

Du koennest bei deinem Schalter einmal die Konfiguration auslesen
(getConfig). Bei einem Schalter (also auch Fensterkontakt) musst du erst
das Kommando in fhem absetzen - dann siehst du ein den prot... attributen
(es sind noch viele mehr) das Kommandos 'pending' sind. Du musst 'anlernen'
ausloesen, dann werden die Daten gelesen

Die Frage ist dann, mit wem dein Schalter gepeert ist (peerList) und mit
wem gepairt (PairedTo in readings).

Kannst es dann gerne einmal posten - mit "list" zum Beispiel.

Gruss
Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

> Aktuell steht z.B. in peerList von Bad_Temp_WindowRec
> "Bad_Fenster_chn:01,"
> Bin mir allerdings fast sicher, dass dort vorher nur "Bad_Fenster" ohne
> Kanal stand...
>

das ist ok - ist nur etwas genauer. Bad_Fenster ist sicher ein Schalter mit
nur einem Kanal. Somit benutzt man nur das Device - und den Kanal 01
implizit.
Kanal 01 ist also in -jeden- geraet vorhanden - da  jedes geraet mindestens
eine Funktion hat.

Ich habe das ganze handling geaendert und homogenisiert. Damit sollen (wenn
ich alle erwischt habe)
- peerList und RegListen gleiche Namen haben
- renames von Kanaelen Funktionieren
 In den Ersten Versionen hatte ich den Fokus noch nicht.

Was ist diene Frage - und wo vermisst du das System?

Gruss
Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

>
> Das habe ich mit allen HM Komponenten gemacht die ich so besitze (So wie
> früher auch, da lief es ja bis zu dem ominösen Update)
>
da hat sich auch nichts geaendert. Das pairing mit  der Zentrale ist (nehme
ich an) korrekt und du hast es jetzt noch einmal gemacht. Das wird das
Verhalten deine Lampe nicht aendern, da es mit dem pairen zu einer Zentrale
nie etwas zu tun hatte.

Die Frage ist,mir wem dein Schalter gepeert ist - also welchen Aktor er
sucht.Der ist fuer den ACK nach dem Schalter verantwortlich. Hier musst du
die peerlist ansehen. Die wurden schom immer durch devicepair gesetze -
oder per HMconfig - oder durch direktes anlernen.



> So, also eigentlich einfach zu verstehen oder? Hoffe ich ... Mich wundert
> eben nur das ich zunehmend immer mehr Leute antreffe wo es vorher
> Wochenlang lief und seit dem Update exakt dasselbe Problem vorliegt. Nun
> habe ich ja verstanden, dass es zwei Modi gibt.

nein,zwei "Modi" gibt es nicht sonders 2 parameter - parallel

Ich möchte aber das alle Sensoren and FHEM angemeldet werden als wenn FHEM
> eine Zentrale ist, so wie ich bis jetzt davon ausgegangen bin das es immer
> so war und ich es jetzt auch so gemacht habe.

das kann ich nur unterstuetzen.
 

> Die ganzen "Unterkanäle" sollten ja dann automatisch angelegt werden,
> zumindest war es bis jetzt immer so. Wenn ich das TC anlerne seh ich ja
> auch mit einmal die 3 Kanäle von dem Teil.
>
nun - schon immer nicht, erst seit ein paar Wochen

>
> Und an einer falschen Anmeldung kann es ja nicht liegen weil es lief ja
> ca. 4 Stunden. Das ist ja nicht so das FHEM nach 4 Stunden einfällt, misst
> die Geräte sind falsch gepaired jetzt habe ich kein Bock mehr den Sensoren
> zu Antworten oder?
>
Dass sich etwas nach 4 Stunden aendert  ist seltsam. Koennte daran liegen,
dass sich das Device regelmaessig meldet.

>
> Ich hab echt keine Ahnung wie ich das noch ausdrücken soll Und viel
> schlimmer, ich hab keine Ahnung was ich hier genau falsch mache
>

a) es gibt eine neue Version - die habe ich gerade eingestellt - kommt also
nicht automatisch per update.Hier koennte es wieder Funktionieren, wenn das
Problem die Rueckmeldung des Triggers war.
b) falls es nicht funktioniert - oder auch so - koenntest du mit ein paar
traces schicken. Setze global verbose auf 1 und HMLAN loglevel auf 1. Dann
deine Aktionen laufen lassen. Alles was ich brauche sollte im Log stehen

Gruss
Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[eppi]

                                               

Hallo Martin
Ich habe getconfig abgesetzt:
 
protCmdDel 2
protCmdPend 3 CMDs_pending
protLastRcv 2012-11-16 12:22:58
protResndCnt 2
protResndFailCnt 1  
protResndFailLast 2012-11-16 11:35:51
protResndLast 2012-11-16 11:35:50
protSndCnt 4
protSndLast 2012-11-16 11:36:09
 
Ein List gibt folgendes aus:
   CUL_HM_EG_MSGCNT 6
   CUL_HM_EG_RAWMSG
A1AB084001691D900000020002F49455130303539333835808101010F
   CUL_HM_EG_RSSI -66.5
   CUL_HM_EG_TIME 2012-11-16 12:22:58
   DEF        1691D9
   HMLAN1_MSGCNT 5
   HMLAN1_RAWMSG
E1691D9,0000,08E8F634,FF,FFB3,B084001691D900000020002F4945513030353933383580810101
   HMLAN1_RSSI -77
   HMLAN1_TIME 2012-11-16 12:22:58
   HMLAN2_MSGCNT 5
   HMLAN2_RAWMSG
E1691D9,0000,08E8AC12,FF,FFAC,B084001691D900000020002F4945513030353933383580810101
   HMLAN2_RSSI -84
   HMLAN2_TIME 2012-11-16 12:22:58
   IODev      HMLAN2
   LASTIODev  CUL_HM_EG
   MSGCNT     6
   NAME       Fenster_Kueche
   NR         389
   STATE      open
   TYPE       CUL_HM
   lastMsg    No:B0 - t:00 s:1691D9 d:000000
20002F4945513030353933383580810101
   Readings:
     2012-11-16 11:36:09   CommandAccepted yes
     2012-11-16 12:22:09   alive           yes
     2012-11-16 12:22:09   battery         ok
     2012-11-16 12:22:09   contact         open (to CUL_HM_EG)
     2012-11-16 12:22:09   cover           open
     2012-11-16 12:22:09   state           open
   cmdStack:
     ++A0017ADFC51691D900040000000000
     ++A0017ADFC51691D90103
     ++A0017ADFC51691D901040000000001
   Helper:
     addVal     14
     getCfgList all
     getCfgListNo 4
     mId        002F
     rxType     12
     Respwait:
Attributes:
   actCycle   028:00
   actStatus  unknown
   devInfo    810101
   firmware   2.0
   hmClass    sender
   model      HM-SEC-SC
   protCmdDel 2
   protCmdPend 3 CMDs_pending
   protLastRcv 2012-11-16 12:22:58
   protResndCnt 2
   protResndFailCnt 1
   protResndFailLast 2012-11-16 11:35:51
   protResndLast 2012-11-16 11:35:50
   protSndCnt 4
   protSndLast 2012-11-16 11:36:09
   room       Fenster
   serialNr   IEQ0059385
   subType    threeStateSensor

Du schreibst, dass ich "anlernen" auslösen muss. Ist da hmPairSerial
gemeint? Muss dem Fensterkontakt zuerst ein IODev zugeortnet werden, da ich
ein CUL im HM-Mode und zwei HM-LAN Adapter verwende?
 
Danke für die Hilfe und Gruss Eppi

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[ext23]

                                                 

> Die Frage ist,mir wem dein Schalter gepeert ist - also welchen Aktor er
> sucht.Der ist fuer den ACK nach dem Schalter verantwortlich. Hier musst du
> die peerlist ansehen. Die wurden schom immer durch devicepair gesetze -
> oder per HMconfig - oder durch direktes anlernen.
>
Mhh mit garkeinem Aktor, ich habe das Teil nur mit FHEM verbunden, mit
niemanden anderen. Ein getconfig und getpairdevice ergab folgendes:
PairedTo 23FF23 (Das ist mein HMLAN Adapter, passt also)
peerIDs (das ist leer, steht nichts hinter)

icht so das FHEM nach 4 Stunden einfällt, misst die Geräte sind falsch
> gepaired jetzt habe ich kein Bock mehr den Sensoren zu Antworten oder?
> Dass sich etwas nach 4 Stunden aendert  ist seltsam. Koennte daran liegen,
> dass sich das Device regelmaessig meldet.
>
Mhh jo wie auch immer... aber trotzdem ein Bug
 

> a) es gibt eine neue Version - die habe ich gerade eingestellt - kommt
> also nicht automatisch per update.Hier koennte es wieder Funktionieren,
> wenn das Problem die Rueckmeldung des Triggers war.
>
OK werde ich prüfen, zieh ich mir nachher mal runter, von wo auch immer,
aber das find ich schon
 

> b) falls es nicht funktioniert - oder auch so - koenntest du mit ein paar
> traces schicken. Setze global verbose auf 1 und HMLAN loglevel auf 1. Dann
> deine Aktionen laufen lassen. Alles was ich brauche sollte im Log stehen
>
Das mache ich dann auf jeden Fall, das war ja mein Anliegen was genau ich
sammeln muss um dir zu helfen
 

>
> Gruss
> Martin
>
Gruß und Danke!
Daniel

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[ext23]

                                                 

Anbei noch das Log (Auszug) nachdem ich beide Loglevel auf 1 gesetzt habe.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

2012.11.16 20:48:20 1: HMLAN_Parse: HMLAN1 S:E1D259A   stat:0000 t:525A49AC d:FF r:FFBCm:9A86701D259A00000000CC3F
2012.11.16 20:48:27 1: HMLAN_Send:  K
2012.11.16 20:48:27 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0062180 d:1399AF O:23FF23 m:525A64F0 d2:0000
2012.11.16 20:48:31 1: HMLAN_Parse: HMLAN1 S:E1B87A7   stat:0000 t:525A7608 d:FF r:FFAEm:1CA4411B87A723FF230116C8
2012.11.16 20:48:31 1: HMLAN_Parse: HMLAN1 S:E1B87A7   stat:0000 t:525A7706 d:FF r:FFAFm:1CA0411B87A723FF230116C8
2012.11.16 20:48:32 1: HMLAN_Parse: HMLAN1 S:E1B87A7   stat:0000 t:525A7901 d:FF r:FFAEm:1CA0411B87A723FF230116C8
2012.11.16 20:48:33 1: HMLAN_Parse: HMLAN1 S:E1B87A7   stat:0000 t:525A7CF6 d:FF r:FFAEm:1CA0411B87A723FF230116C8
2012.11.16 20:48:35 1: HMLAN_Parse: HMLAN1 S:E1B87A7   stat:0000 t:525A84E0 d:FF r:FFAEm:1CA0411B87A723FF230116C8
2012.11.16 20:48:39 1: HMLAN_Parse: HMLAN1 S:E1B87A7   stat:0000 t:525A94B7 d:FF r:FFAEm:1CA0411B87A723FF230116C8
2012.11.16 20:48:40 1: HMLAN_Parse: HMLAN1 S:E1D259A   stat:0000 t:525A97CF d:FF r:FFBCm:9AA2581D259A1D22C40000
2012.11.16 20:48:40 1: HMLAN_Parse: HMLAN1 S:E1D22C4   stat:0000 t:525A9853 d:FF r:FFC0m:9A82021D22C41D259A0101000043
2012.11.16 20:48:40 1: HMLAN_Send:  -1D22C4
2012.11.16 20:48:40 1: HMLAN_Send:  +1D22C4
2012.11.16 20:48:52 1: HMLAN_Send:  K
2012.11.16 20:48:52 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0062180 d:1399AF O:23FF23 m:525AC6A8 d2:0001
2012.11.16 20:49:17 1: HMLAN_Send:  K
2012.11.16 20:49:17 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0062180 d:1399AF O:23FF23 m:525B2872 d2:0001

[ext23]

                                                 

So nach dem Update heute geht wieder alles auf Anhieb.

Auch wenn nach dem Update folgende Meldung kam:

Backup:
tar: Removing leading `/' from member names
backup done: FHEM-20121117_105214.tar.gz (1911021 Bytes)

8 file(s) have been updated:
==> 2012-11-17 07:45:14 FHEM/00_HMLAN.pm
==> 2012-11-17 07:45:14 FHEM/10_CUL_HM.pm
==> 2012-11-17 07:45:14 FHEM/40_RFXCOM.pm
==> 2012-11-17 07:45:14 FHEM/45_TRX.pm
==> 2012-11-17 07:45:14 FHEM/46_TRX_WEATHER.pm
==> 2012-11-17 07:45:14 FHEM/71_YAMAHA_AVR.pm
==> 2012-11-17 07:45:14 FHEM/98_XmlList.pm
==> 2012-11-17 07:45:15 docs/commandref.html

Module(s) reloaded:
==> 00_HMLAN
==> 10_CUL_HM:
Not enough arguments for main::CUL_HM_SendCmd at
/usr/share/fhem/FHEM/10_CUL_HM.pm line 572, near
""++803F$id${src}0204$s2000")"
Not enough arguments for main::CUL_HM_SendCmd at
/usr/share/fhem/FHEM/10_CUL_HM.pm line 826, near ""0101${state}00")"
Not enough arguments for main::CUL_HM_SendCmd at
/usr/share/fhem/FHEM/10_CUL_HM.pm line 884, near "))"
Not enough arguments for main::CUL_HM_SendCmd at
/usr/share/fhem/FHEM/10_CUL_HM.pm line 928, near ""8002$id$src${chn}00")"
Not enough arguments for main::CUL_HM_SendCmd at
/usr/share/fhem/FHEM/10_CUL_HM.pm line 961, near ""00")  
          "
Not enough arguments for main::CUL_HM_SendCmd at
/usr/share/fhem/FHEM/10_CUL_HM.pm line 1030, near ""00")"
Not enough arguments for main::CUL_HM_SendCmd at
/usr/share/fhem/FHEM/10_CUL_HM.pm line 1038, near ""00")"
Not enough arguments for main::CUL_HM_SendCmd at
/usr/share/fhem/FHEM/10_CUL_HM.pm line 1047, near ""00")  # Send Ack
      "
BEGIN not safe after errors--compilation aborted at
/usr/share/fhem/FHEM/10_CUL_HM.pm line 1656.

==> 98_XmlList

Update completed!

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

> So nach dem Update heute geht wieder alles auf Anhieb.
>
gut

>
> Auch wenn nach dem Update folgende Meldung kam:
>
> ==> 10_CUL_HM:
> Not enough arguments for main::CUL_HM_SendCmd at
> /usr/share/fhem/FHEM/10_CUL_HM.pm line 572, near
> ""++803F$id${src}0204$s2000")"
> BEGIN not safe after errors--compilation aborted at
> /usr/share/fhem/FHEM/10_CUL_HM.pm line 1656.
>
> habe es gehoert. Ist unschoen, sollte aber kein Problem sein. Kommt "nur"
einmal beim Update. Es hat sich eine Funktion geaendert und im Update
scheint zu einem Zeitpunkt noch den alten Prototyp verwenden

Gruss
Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo,

ich versuch es einmal
- die Begriffe sind m.E. schlecht gewaehlt. Aber auf der Hand liegend habe
ich auch nichts - mal sehen

es gibt 2 unterschiedliche Paarungen
A) Paaren mit der Zentrale
- Kommandos sind pair (setzen) und getpair lesen.
- es wird das Device (also einmal pro Geraet) gepairt. Diese Paarung sagt
dem Device, dass es eine Zentrale gibt.Ab dann werden Statusmeldungen an
die selbe abgesetzt, wenn ich ein Zustand geaendert hat und aehnliches.
Eigentlich ist es ein 'asign'
- Das pairing steht implizit in der Registerliste  0 RegL_0. Wenn man
getConfig ausfuehrt wird es auch immer gelesen.
- Der Zustand kann im Reading Paired to gelesen werden.
Roter Faden: pair in allen Varianten ist die Zentrale
Kommandos wie pair haben evtl eih pendant getpair. get<...> ist immer das
Lesen.
Dass das ganze set get<...> heisst kommt davon, dass ich keinen Wert
direkt zurueckgeben kann, da es zu lange dauert. Alle bisherigen "get
..." gehen auf den fhem speicher.
Merke: 1 Geraet, 1 Zentrale

B) peers
- werden behandelt mit devicepair und abgefragt mit getdevicepair.
getConfig liest auch diese Parameter. getConfig liest eigentlich alle
device-konfigurationen.
- peers werden benutzt zum kommunikation eines Senders mit einem aktor -
ohne Zentrale.
- HM spricht hier auch von Links - korrekt ist der Link die Verbindung
zwischen peers. Ich werde hier jetzt nicht mehr von peers sprechen sondern
von links - zur besseren Unterscheidung
- Nach den devicepair (oder dem externen Anlernen eines Links,egal wie man
es gemacht hat) kann man die Daten im Reading peerList sehen. Update dieser
Liste wie gesagt getdevicepair oder getConfig
- Links werden je Kanal eingerichtet. Ein Geraet mit 2 Lichtschaltern hat 2
Kanaele. Ein Taster RC12 hat 12 Kanaele. Eine RC19 hat 18... da sind noch
ein paar sonder Kanaele. Ein TC hat 3 spezielle......
Jeder Kanal verwaltet seine eigenen Links - so er den welche hat. Du willst
ja nicht immer beide Lichter einschalten...) Jeder Kanal kann mehrere links
haben. Ein taster kann mehrere Aktoren ansteuern, ein Aktor kann von
mehreren Schaltern angesteuert werden.
- Ein Taster oder sender sendet seine Trigger normal als Broadcast. Am Ende
fragt er jeden seiner Links ab und erwartet eine Statusmeldung. Es ist
dabei egal, wie der Status ist, wichtig ist einzig, dass eine Rueckmeldung
kommt. Die meisten Sender sind hier gleich, egal ob Fensterkontakt oder
remoteControl,... Die sind austauschbar.
Einstellbare Parameter gibt es wenig. Zugehoerige Registersetting zu den
Links sind in RegL4 zu finden
- Ein AktorKanal hat deutlich mehr zu beachten in Sachen Links. Schoenes
Beispiel sind dimmer. Hier wird gerne ein paar Taster angelernt. In
realitaet werden 2 Links erzeugt. Fuer jeden dieser Links werden parameter
automatisch generiert. So wird der eine Link zum hochdimmen und der andere
zum runterdimmen eingestellt. Wenn man die Register in List3 zu diesen
Links veraendert kann man es auch umkehren,...
Wenn man nur einen Link einbaut (devicepair ...single) dann wird ein Link
parametrisiert, der hochdimmen und runterdimmen toggelt.


Man unterschiedet also Links sendeseitig ( buttons,...) und Links
Empfangsseitig (aktoren).

Ich empfehle auch die Lektuere des Einsteigerdoc. Im hinteren Teil habe ich
mich an ein paar Beschreibungen versucht.

Ich hoffe,das hat etwas geholfen.
Nach dem feedback trage ich mich mit dem Gedanken peers durch Links zu
ersetzen... waere das gut?

Gruss
Martin

PS: getConfig laed alle Daten der Einheit. Wenn man es also auf einen
Button anwendet werden nur die Daten des Kanals geladen.
Wenn man es auf ein device anwendet werden alle zugehoerigenKanaele
auchgeladen (also alle 12 buttons eine RC12)



--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[ext23]

                                                 

Super danke, so langsam habe ich es geschnallt!

Übrigens getpair und getconfig etc. funktioniert alles nicht mehr, ich hab
hier
"protCmdPend5 CMDs_pending deleteattr"

Aber gut ein Fenster Sensor ist denkbar schlecht als beispiel, da muss man
doch immer die Anlern Taste drücken damit man was auslesen kann oder?
Zumindest kenne ich es so von der HMConfigSoftware.

Aber mein TC mag auch nicht, da habe ich schon 20 Commandos im pending.
Also irgendwas ist da faul.

Vermutlich muss ich die Geräte am WE wirklich alle nochmal anmelden. Du
hast ja in dem Dokument geschrieben man soll es dann über die Seriennummer
machen und nicht mit diesem Modus wo man die Sekunden angibt in denen FHEM
wartet auf ein "pair".

Übrigens hattest du das in dem Dokument schon sehr gut beschrieben, ich
wusste nicht das da schon ein Update kam. Damals stand das noch nicht so
schön Beschrieben im appendix

Ich seh schon, das wird ein langes bastel Wochenende für mich


Am Mittwoch, 14. November 2012 18:14:47 UTC+1 schrieb Martin:
>
> Hallo,
>
> ich versuch es einmal
> - die Begriffe sind m.E. schlecht gewaehlt. Aber auf der Hand liegend habe
> ich auch nichts - mal sehen
> ....
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Am Mittwoch, 14. November 2012 18:52:38 UTC+1 schrieb Ext23:
>
> Super danke, so langsam habe ich es geschnallt!
>
> Übrigens getpair und getconfig etc. funktioniert alles nicht mehr, ich hab
> hier
> "protCmdPend5 CMDs_pending deleteattr"
>

das wiederum ist eine andere Eigenheit von HM.
a) FHEM hat einen Commandstack aud den Kommandos gequeued werden bis sie
zum Senden dran sind. In vielen Faellen werden die Kommandos schnell
abgearbeitet, da bemerkst du den Stack und den Status garnicht.
b) HM hat nun 3 (eigentlich4) aufwachmodi
  - immer wach. I.A. schalter mit Stromanschluss. Kommandos werden sofort
verarbeitet. FHEM startet die Verarbeitung sofort
  - regelmaessig aufwachen. Beispielsweise ein Thermostat (TC). der wacht
alle 3 min auf. FHEM wartet bis es ein Aufwachen sieht und schickt dann
schnell die messages. In der zwischenseit kannst du ueber die Attribute
sehen, on und wieveile Kommandos in der Schlange warten
  - 'Config' mode - der haesslichste. Das Device verarbeitet kommandos nur.
wenn man 'anlernen' drueckt. FHEM kann dies erkennen und wartet
entsprechend. Es gibt keine Moeglichkeit dies zu umgehen - leider. Die
meisten Fernbedienungen scheinen diesen Mode zu haben.
  - einen burst mode gibt es auch - der ist aber nicht erheblich.

Der Vollstaendigkeit halber: manche devices koennen 2 Modi - der TC kann
config und wacht regelmaesig auf. Meine RC12 leider nicht - hier muss ich
anlernen druecken.

Problematisch sind also die 'config' teile. Da bei dir die kommandos in der
queue sind kannst du einfach config druecken und fhem wird den Stack
abarbeiten.

Das groesste Problem stellen die eingebauten Schalter dar, bei denen man an
den Config Knopf nicht ran kommt.So einen habe ich auch....

Zur Info: Die kommandos werden abgearbeitet - die vorhandene Konfiguration
geht nicht verloren (es sein den man ueberschreibt sie - dann natuerlich
schon)
 

> Aber gut ein Fenster Sensor ist denkbar schlecht als beispiel, da muss man
> doch immer die Anlern Taste drücken damit man was auslesen kann oder?
> Zumindest kenne ich es so von der HMConfigSoftware.
>
korrekt

>
> Aber mein TC mag auch nicht, da habe ich schon 20 Commandos im pending.
> Also irgendwas ist da faul.
>
der sollte schon. Evtl einfach mal anlernen (ok 20 sec) dann wird es  
ausgelesen.
Halt - mach vorher einmal einen jsonlist - vielleicht ist etwas faul in
meiner SW... kann ich einmal schauen, ob die queue haengt...

>
> Vermutlich muss ich die Geräte am WE wirklich alle nochmal anmelden. Du
> hast ja in dem Dokument geschrieben man soll es dann über die Seriennummer
> machen und nicht mit diesem Modus wo man die Sekunden angibt in denen FHEM
> wartet auf ein "pair".
>
ich habe geschrieben, dass ich es so mache. Es gibt mehrere Wege, das ist
meiner.  

>
> Übrigens hattest du das in dem Dokument schon sehr gut beschrieben, ich
> wusste nicht das da schon ein Update kam. Damals stand das noch nicht so
> schön Beschrieben im appendix
>
> Ich seh schon, das wird ein langes bastel Wochenende für mich
>
viel Spass

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com