Frage zu CUL_HM regSet & Co

[Guest]

Originally posted by: <email address deleted>

Hallo,

bei CUL_HM wurde ja immens was eingebaut, um die ganzen Register der
Aktoren usw. zu beschreiben - ganz tolle Sache. Leider verstehe ich glaub
ich aus der commandref nicht genau, wie es geht:

Beispiel: Ich habe einen UP-Dimmer und möchte den OnLevelShort für den fest
verdrahteten Taster ändern. Der fest verdrahtete Taster ist ja ein Peer,
wobei der Peer das Device selbst ist.

getDevicePair zeigt mir schonmal eine Liste der Peers. Mein Device hat nur
einen channel und ist als "dim_flur" definiert.

2012-11-09 08:54:33   peerList        
,dim_flur,13C86C_chn:04,13C86C_chn:01,taster_eingang,

Ich weiss nicht ob vor dem ersten Komma was fehlt, jedenfalls ist offenbar
dim_flur auch als Peer drin, was richtig ist, also der eigene Taster.
AUßerdem sind noch zwei Kanäle der Zentrale sowie ein Taster gepeert.

Nun tue ich folgendes:

fhem>  set dim_flur regSet OnLevelSh ? 0
dimmer - OnLevelSh range:0 to 100% peer required : Short:PowerLevel on

Aha. Ich versuche basierend auf diesem Hinweis:

set dim_flur regSet OnLevelSh 100 dim_flur

damit wollte ich also den Level auf 100% setzen. Ergebnis: NACK. Meine
Vermutung also, es reicht nicht der Name sondern es muss die 4 Byte ID (3
Byte Device + Channel) her.

list dim_flur
 DEF        15A2DB

also:

set dim_flur regSet OnLevelSh 100 15A2DB01

Ergebnis: NACK

Was mache ich falsch?

VG

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

[Guest]

Originally posted by: <email address deleted>

> bei CUL_HM wurde ja immens was eingebaut, um die ganzen Register der
> Aktoren usw. zu beschreiben - ganz tolle Sache. Leider verstehe ich glaub
> ich aus der commandref nicht genau, wie es geht:
>

Ich habe eine "prosaischere"  Beschreibung im Einsteiger Doc abgegeben -
und deren Version 4 ist in der "Veroeffentlichungspipe". Commandref ist
nicht wirklich fuer prosa, scenarien und Hintergrund geeignet. In Wiki ist
es fuer mich zu zerfleddert - nichts gegen Wikki, ist sehr gut, aber das
was ich abgebe habe ich lieben in einer Art Handbuch - da verliere ich
nicht sooo schnell den Ueberblick. Neben den Codieren und debuggen reicht
mir dass dann.

>
> Beispiel: Ich habe einen UP-Dimmer und möchte den OnLevelShort für den
> fest verdrahteten Taster ändern. Der fest verdrahtete Taster ist ja ein
> Peer, wobei der Peer das Device selbst ist.
>
> getDevicePair zeigt mir schonmal eine Liste der Peers. Mein Device hat nur
> einen channel und ist als "dim_flur" definiert.
>
 
Tip: getConfig beinhaltet getdevicepair und mehr

>
> 2012-11-09 08:54:33   peerList        
> ,dim_flur,13C86C_chn:04,13C86C_chn:01,taster_eingang,
>
> Ich weiss nicht ob vor dem ersten Komma was fehlt, jedenfalls ist offenbar
> dim_flur auch als Peer drin, was richtig ist, also der eigene Taster.
> AUßerdem sind noch zwei Kanäle der Zentrale sowie ein Taster gepeert.
>

Das ist die Peerlist und ist fakt. Das erste Komma ist immer da, ich habe
es mir beim schreiben einfach gemacht, so muss ich den ersten Eintrag nicht
gesondert behandeln. Also aktuell Systembedingt und korrekt.
Der interne Schalter ist per default gepairt. Er ist aber nicht immer
sichtbar - nur wenn du die internen keys visible setzt. Per HM-default ist
dies off - du hast sie also irgendwann einmal eingeschaltet.
Die anderen Peers hast du sicher irgendwann einmal addiert. Ich gebe es
human readable nach best-effort aus. Gepairt sind IMMER kanaele, NIE
devices. - macht ja Sinn. Reihenfolge der namensaufloesung ist also
channelname - falls der Kanal definiert ist
devicename - falls es Kanal 01 ist und der Kanal definiert ist
devicename_chn: - falls das device existiert aber der Kanal nicht
HMid_chn: - wenn kein name gefunden wurden in CUL_HM (deshalb wird das
IO-device nicht ersetzt, ist eine Schwachstelle...)

 

>
> Nun tue ich folgendes:
>
> fhem>  set dim_flur regSet OnLevelSh ? 0
> dimmer - OnLevelSh range:0 to 100% peer required : Short:PowerLevel on
>
> Aha. Ich versuche basierend auf diesem Hinweis:
>
> set dim_flur regSet OnLevelSh 100 dim_flur
>

hier muss ich noch nachbessern. Ist zwar alles im commandref beschrieben
(siehe self...)  aber ist nicht gleich WISIWIG

Erklaerung - bis ich eine andere Loesung habe:
Du hast gleich mit den sonderteil angefangen
1) was du gemacht hast sollte bei allen externen und komplett definierten
peers funktionieren - also fuer taster_eingang.
2) die "internen peers" kann man mit "self" setzen - was du wolltest
ist also erreichbar mit
set dim_flur regSet OnLevelSh 100 self1
Note1: devices haben bis zu 4 interne Kanaele (mehr habe ich bisher nicht
gesehen). Die Zuordnung channel zu internal peer ist logisch aber 'direkt'.
Ein dimmer hat 2 interne peers, ein schalter einen. Somit hat ein 2-Kanal
dimmer Channes 1: self01, self02 Channle 2:self3,self4. (self3 oder self03
ist gleich) Ein switch hat channel : self1, channel2, self2
Note2: Das bearbeiten den interne Channel funktioniert nur, wenn die
internen keys visible sind.


Dein Versuch mit
set dim_flur regSet OnLevelSh 100 15A2DB01
sollte funktionieren.
A) kannst du ein getConfig machen und das Ergebnis posten
B) kannst du die logs mitschneiden, wenn es nicht funktioniert?


Aenderungen in CUL_HM, neuster Stand peer listen
Ich musste die organisation intern etwas aendern. Jetzt werden peerIDs
verwaltet, die ich intern brauche (um fuer rename gewappnet zu sein) und
eine peerList in lesbarer Form, also wie bisher. Beides als Attribut,
peerList auch in Readings. Seit heute Nacht.

Aufgrund deiner Anmerkung (und weil ich das Problem schon gesehen habe)
werde ich in der Peerlist "self" fuer das eigene Device einbauen.

Gruss
Martin



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

[Guest]

Originally posted by: <email address deleted>

Danke für die Erklärungen!

Gibts schon irgendwo den Draft von der Doku? Das klingt ja phantastisch!

Hier mal der Logauszug von dem nicht erfolgreichen set dim_flur regSet
OnLevelSh 100 15A2DB01

2012.11.09 11:35:05 5: Cmd: >set dim_flur regSet OnLevelSh 100 15A2DB01<
2012.11.09 11:35:05 3: CUL_HM set dim_flur regSet OnLevelSh 100 15A2DB01
2012.11.09 11:35:05 5: HMLAN_Send:  
SE4BCBDBC,00,00000000,01,E4BCBDBC,28A00113C86C15A2DB01050000000103
2012.11.09 11:35:05 5: HMLAN_Parse: hmlan S:RE4BCBDBC stat:0001 t:029E97D6
d:FF r:FFC1m:28800215A2DB13C86C84
2012.11.09 11:35:05 5: HMLAN_Send:  +15A2DB
2012.11.09 11:35:05 5: HMLAN_Send:  -15A2DB
2012.11.09 11:35:05 5: HMLAN_Send:  +15A2DB
2012.11.09 11:35:05 5: hmlan dispatch A0A28800215A2DB13C86C84
2012.11.09 11:35:05 5: HMLAN_Send:  
SE4BCBE85,00,00000000,01,E4BCBE85,29A00113C86C15A2DB010811C8
2012.11.09 11:35:05 5: Cmd: >{if($value{dim_wohn} ne "off"){ fhem "set
anwesend 0";}}<
2012.11.09 11:35:05 5: HMLAN_Parse: hmlan S:RE4BCBE85 stat:0001 t:029E9961
d:FF r:FFC2m:29800215A2DB13C86C80
2012.11.09 11:35:05 5: HMLAN_Send:  +15A2DB
2012.11.09 11:35:05 5: HMLAN_Send:  -15A2DB
2012.11.09 11:35:05 5: HMLAN_Send:  +15A2DB
2012.11.09 11:35:05 5: hmlan dispatch A0A29800215A2DB13C86C80

Und hier das getConfig:

fhem> set dim_flur getConfig
fhem> CUL_HM dim_flur RESPONSE TIMEOUT
CUL_HM dim_flur RESPONSE TIMEOUT

list dim_flur

Internals:
   DEF        15A2DB
   IODev      hmlan
   LASTIODev  hmlan
   MSGCNT     29
   NAME       dim_flur
   NR         54
   STATE      NACK
   TYPE       CUL_HM
   hmlan_MSGCNT 29
   hmlan_RAWMSG
E15A2DB,0000,02A0862C,FF,FFC2,3DA01015A2DB13C86C038E2000148C00053400C80A000404
   hmlan_RSSI -62
   hmlan_TIME 2012-11-09 11:37:12
   lastMsg    No:3D - t:10 s:15A2DB d:13C86C 038E2000148C00053400C80A000404
   Readings:
     2012-11-09 11:35:05   CommandAccepted no
     2012-11-09 11:37:03   PairedTo        13C86C
     2012-11-09 11:37:03   RegL_00:          02:81 0A:13 0B:C8 0C:6C 15:05
00:00
     2012-11-09 11:37:05   RegL_01:          30:06 32:50 33:64 34:4B 35:50
00:00
     2012-11-09 11:37:12   RegL_03:13C86C_chn:01  01:00 02:00 03:00 04:32
05:64 06:00 07:25 08:00 09:FF 0A:01 0B:12 0C:22 0D:23 0E:20 0F:00 10:14
11:8C 12:00 13:05 14:34 15:00 16:C8 17:0A 18:00 19:04 1A:04 81:00 82:00
83:00 84:32 85:64 86:00 87:25 88:00 89:FF 8A:26 8B:12 8C:22 8D:23 8E:20
8F:00 90:14 91:8C 92:00 93:05 94:34 95:00 96:C8 97:0A 98:00 99:04 9A:04
     2012-11-09 11:37:09   RegL_03:13C86C_chn:04  01:00 02:00 03:00 04:32
05:64 06:00 07:7E 08:00 09:FF 0A:01 0B:12 0C:22 0D:23 0E:20 0F:00 10:14
11:78 12:00 13:05 14:8F 15:00 16:C8 17:0A 18:00 19:04 1A:04 81:00 82:00
83:00 84:32 85:64 86:00 87:7E 88:00 89:FF 8A:26 8B:12 8C:22 8D:23 8E:20
8F:00 90:14 91:78 92:00 93:05 94:8F 95:00 96:C8 97:0A 98:00 99:04 9A:04
00:00
     2012-11-09 11:37:07   RegL_03:dim_flur  01:00 02:00 03:00 04:32 05:64
06:00 07:B1 08:00 09:FF 0A:01 0B:14 0C:52 0D:63 0E:00 0F:00 10:14 11:C8
12:0A 13:04 14:02 15:00 16:C8 17:0A 18:0A 19:04 1A:04 81:00 82:00 83:00
84:32 85:64 86:00 87:8A 88:00 89:FF 8A:26 8B:14 8C:52 8D:63 8E:00 8F:00
90:14 91:C8 92:0A 93:05 94:94 95:00 96:C8 97:0A 98:0A 99:04 9A:04 00:00
     2012-11-09 11:32:04   deviceMsg       off (to hmlan)
     2012-11-09 11:32:04   dim             stop:off
     2012-11-09 11:37:04   peerList        
,dim_flur,13C86C_chn:04,13C86C_chn:01,taster_eingang,
     2012-11-09 11:35:05   state           NACK
     Regl_03:taster_eingang:
       VAL
   Helper:
     addVal     0
     mId        0059
     rxType     1
     Shadowreg:
       RegL_03:   0 11:C8
Attributes:
   devInfo    110100
   firmware   1.2
   hmClass    receiver
   model      HM-LC-DIM1T-FM
   protCmdDel 4
   protLastRcv 2012-11-09 11:37:12
   protNackCnt 8
   protNackLast 2012-11-09 11:35:05
   protSndCnt 16
   protSndLast 2012-11-09 11:37:13
   protToutRespCnt 2
   protToutRespLast 2012-11-09 11:37:15
   room       CUL_HM
   serialNr   HEQ0358750
   subType    dimmer

Vll. ein Funkproblem? Dinge wie set on/off funktionieren jedenfalls...

VG!

>
>

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

[Guest]

Originally posted by: <email address deleted>

>
> Gibts schon irgendwo den Draft von der Doku? Das klingt ja phantastisch!
>

nun - nicht zuviel erwarten - da ist genug 'room for improvemet' gelassen.
Habe die letzte Version einmal angehaengt. Die Veroeffentlichung uebernimmt
dankbarer weise Uli - sollte in kuerze am web sein - evtl mit ein paar
kleineren Korrekturen...

>
> Hier mal der Logauszug von dem nicht erfolgreichen set dim_flur regSet
> OnLevelSh 100 15A2DB01
>

Habe den Fehler gesehen. Ich teste nur noch selten mit den HMIDs und
benutze lieber die Namen. Muss noch im Code nachsehen, warum, aber ich
denke dass das Problem mit Namen nicht auftritt.  Jedenfalls werde ich es
beheben.

>
>
> Und hier das getConfig:
>
>    Readings:
>      2012-11-09 11:35:05   CommandAccepted no
>      2012-11-09 11:37:03   PairedTo        13C86C
>      2012-11-09 11:37:03   RegL_00:          02:81 0A:13 0B:C8 0C:6C 15:05
> 00:00
>      2012-11-09 11:37:05   RegL_01:          30:06 32:50 33:64 34:4B 35:50
> 00:00
>      2012-11-09 11:37:12   RegL_03:13C86C_chn:01  01:00 02:00 03:00 04:32
> 05:64 06:00 07:25 08:00 09:FF 0A:01 0B:12 0C:22 0D:23 0E:20 0F:00 10:14
> 11:8C 12:00 13:05 14:34 15:00 16:C8 17:0A 18:00 19:04 1A:04 81:00 82:00
> 83:00 84:32 85:64 86:00 87:25 88:00 89:FF 8A:26 8B:12 8C:22 8D:23 8E:20
> 8F:00 90:14 91:8C 92:00 93:05 94:34 95:00 96:C8 97:0A 98:00 99:04 9A:04
>      2012-11-09 11:37:09   RegL_03:13C86C_chn:04  01:00 02:00 03:00 04:32
> 05:64 06:00 07:7E 08:00 09:FF 0A:01 0B:12 0C:22 0D:23 0E:20 0F:00 10:14
> 11:78 12:00 13:05 14:8F 15:00 16:C8 17:0A 18:00 19:04 1A:04 81:00 82:00
> 83:00 84:32 85:64 86:00 87:7E 88:00 89:FF 8A:26 8B:12 8C:22 8D:23 8E:20
> 8F:00 90:14 91:78 92:00 93:05 94:8F 95:00 96:C8 97:0A 98:00 99:04 9A:04
> 00:00
>      2012-11-09 11:37:07   RegL_03:dim_flur  01:00 02:00 03:00 04:32 05:64
> 06:00 07:B1 08:00 09:FF 0A:01 0B:14 0C:52 0D:63 0E:00 0F:00 10:14 11:C8
> 12:0A 13:04 14:02 15:00 16:C8 17:0A 18:0A 19:04 1A:04 81:00 82:00 83:00
> 84:32 85:64 86:00 87:8A 88:00 89:FF 8A:26 8B:14 8C:52 8D:63 8E:00 8F:00
> 90:14 91:C8 92:0A 93:05 94:94 95:00 96:C8 97:0A 98:0A 99:04 9A:04 00:00
>      Regl_03:taster_eingang:
>
> wie ich sehe fehlt eine Registerliste. Ich denke nicht, dass es ein
> Funkproblem ist. HMLAN haben wir noch nich tim Griff. Wenn viele messages
> kommen gibt die Untertasse einfach auf. Habe ich auch manchmal bei
> laengeren Abfragen eines Device (getConfig einer RC12 und alle deren
> Kanaele). Ist aber nicht ein Problem des HMLAN selbst sondern des
> Protokoll. Man muss hin und wieder steuermessages schicken, um sie bei
> Laune zu halten - aber da rate ich immer, welche notwendig sind und wann.
> Hier muss noch etwas getan werden.
>

Gruss
Martin

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

[Guest]

Originally posted by: <email address deleted>

> Wenn man sich was wünschen darf, dann wäre das noch eine Doku der
> Erstellung von virtuellen Kanälen - auch da werde ich aus der commandref
> entweder nicht schlauch oder es geht bei mir aus ähnlichen Gründen wie das
> andere nicht ...
>

angekommen. Mittlerweile sollte es auch als Virtual Aktor arbeiten - hatte
sich jemand gewuenscht.  

>
> Ist eig. bekannt wie oft man in das NAND-Flash der Devices schreiben kann?
> Das ist doch sicher irgendwie begrenzt...
>

Keine Ahnung, was eq3 einsetzt. Heutige HW sollte aber eigentlich nicht
unter 10.000 cyclen(schon vor 15 Jahren) eigentlich ueber 100.000 cycle
leigen. In der Praxis dann noch mehr, dies sind uebliche
Herstellergarantien. Aber natuerlich ohne Gewaehr.

Ich gehe davon aus, das ich es mit normalen Aktionen . incl einiger
Testphasen nicht schrotten kann. - Auch ohne Gewaehr.

Gruss
Martin

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

[Guest]

Originally posted by: <email address deleted>

Nachtrag: Ich sehe, dass ich auch 'self' geschlachtet habe bein den letzten
Umstellungen der PeerListen. Wird korrigiert. Funktionieren sollten im
Augenblick nur 'externe Namen'

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

[Guest]

Originally posted by: <email address deleted>

ok teste ich abends nochmal, danke!

bezüglich der Cycles war nur die Frage, weil ih hätte ein paar
Anwendungsfälle wo ich automatisch das FLasch bis zu 5 mal am Tag neu
schreiben würde. Beispiel: Verhalten von Dimmern abhängig von der Tageszeit
und der Außenhelligkeit. Jaja ich weiss, ist extrem ... aber wer nachts
aufs Klo geht braucht es nicht so hell...

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

[Guest]

Originally posted by: <email address deleted>

Ich muss noch einmal bremsen: Warte mit dem peerlisten setzen bis ich alles
korrigiert habe. Dann sollten die peernamen durchgaengig in den Peerlisten,
den regslisten und den User-interfaces sein. Ist etwas mehr wie gedacht...

Zum schreiben - extrem-writing kann ich natuerlich keien Aussage machen.
Schon mal daran gedacht hier virtuelle Schalter zu bemuehen? Ich kenne ja
den Anwendungsfall nicht. Ich denke aber an
- define 5 virtual buttons und paire sie mit im Aktor
- kopple die realen Buttons ueber die Virtuellen mit dem Aktor ueber FHEM

=> was nicht geht, ist den Internen ueber fhem zu koppeln. Alles andere ist
moeglich.


 

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

[Guest]

Originally posted by: <email address deleted>

ja das würde ich am liebsten so machen aber es ist leider der reale Button.
Den hab ich an mehrere Taster die im Treppenhaus verteilt sind in Reihe
angeschlossen. Also den gibts praktisch 4 mal.

Ich werde auf das Extrem Writing wohl auch verzichten. Ich überlege einen
anderen Ansatz: Der Taster dimmt immer sehr schnell auf z.B. 20% hoch und
dann macht fhem den Rest. Aber mal sehen wie die Latenz ist. Könnte für den
Anwender (meine Frau) zu sehr holprig sein.

Es ist echt ein Jammer, dass HM nicht die internen Taster als unabhängige
Sender nutzt. Das wäre ja in der HW alles vorhanden gewesen aber die
Firmware kann es nicht. Ob das Absicht ist?

VG

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

[Guest]

Originally posted by: <email address deleted>

> Es ist echt ein Jammer, dass HM nicht die internen Taster als unabhängige
> Sender nutzt. Das wäre ja in der HW alles vorhanden gewesen aber die
> Firmware kann es nicht. Ob das Absicht ist?
>

ja schade - sind schon mehr reingefallen

Du kannst aber beim dimmer den startlevel auch einstellen, falls es etwas
hilft.
Klar ist sicher,dass du kurz und lang separat programmieren kannst. du hast
also in einem Dimmer 4optionen zu programmieren

>
>
>

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

[Guest]

Originally posted by: <email address deleted>

Hallo unimatrix,

die version von heute Nacht sollte die Probleme loesen, hoffe ich.
Ich habe jetzt WISIWYG eingebaut - hoffentlich ueberall. Sind mittlerweile
ein paar Ecken. Sprich: die Peerlist, der name der Reglisten und die
Kommandos sollten jetzt alle die gleiche Nomenklatur der Channels und
devicenamen benutzen - und bugs aus der letzten Version sollten auch
draussen sein.
Ausserdem sollte das rename nun keine Probleme bereiten (haette so schnell
evtl keiner bemerkt...)
Interne Kanaele hiessen self01,self02.... (geht auch self1)

Kanaele der Zentrale hiessen fhem01, fhem02.... an die kommt aber noch fast
keiner ran (ausser winmatic user,die haben da was eigentuemliches gebaut...
sehr speziell)


Gruss,
Martin

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

[Guest]

Originally posted by: <email address deleted>

kurz/lang ist klar. Lang bei Dimmern habe ich aber im ganzen Haus wirklich
als Dimmen programmiert, das ist ja auch sinnvoll und meine Family hat sich
daran gewöhnt. Also abwechselnd rauf und runterdimmen.

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

[Guest]

Originally posted by: <email address deleted>

ok habe mal ein update gemacht. Ergebnis:

Das obige Beispiel (dim_flur Helligkeit interner Taster ändern) hat beim 1.
Versuch über HMLAN funktiiert. Es kam ein ACK zurück. Außerdem hat es sich
auch tatsächlich entsprechend ausgewirkt (also es wurde nicht mehr sehr
hell bei Einstellung 10%)

getConfig liefert einen haufen RESPONSE_TIMEOUTS über HMLAN. Also habe ich
kurzerhand auf CUL umgestellt (zur Sicherheit den HMLAN sogar vom Netz
genommen). Ergebnis: Schalten on/off geht (CUL funktioniert also) aber
getConfig liefert auch RESPONSE_TIMEOUTS. bei einem get ... reg all sieht
man manchmal auch peers, meistens aber nur wenige Zeilen.

Mit dem CUL hat das setzen OnLevelSh zurück auf 100 auch geklappt. Aber
erst nach 3 Versuchen, bei den ersten beiden kam NACK.

Für mich jetzt kein großes Problem. Bei einer manuellen Konfiguration kann
ich mit mehreren Versuchen leben. Wenn man es als Automatismus einsetzen
würde, wäre es natürlich schlecht.

Ich habe 4 gleichartige Dimmer im Haus verteilt. Von 2 Meter Entfernung zum
HMLAN bishin zu 3 Etagen entfernt. Schalten geht immer ohne Probleme und
dieses Konfig-Zeug ist überall gleich unzuverlässig.

Das also als kurze Wasserstandsmeldung!

Viele Grüße!

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

[Guest]

Originally posted by: <email address deleted>

Am Samstag, 10. November 2012 17:48:51 UTC+1 schrieb unimatrix:
>
> ok habe mal ein update gemacht. Ergebnis:
>
> Das obige Beispiel (dim_flur Helligkeit interner Taster ändern) hat beim
> 1. Versuch über HMLAN funktiiert. Es kam ein ACK zurück. Außerdem hat es
> sich auch tatsächlich entsprechend ausgewirkt (also es wurde nicht mehr
> sehr hell bei Einstellung 10%)
>

gut - hatte es zwischendurch leider einmal versaut...  

>
> getConfig liefert einen haufen RESPONSE_TIMEOUTS über HMLAN. Also habe ich
> kurzerhand auf CUL umgestellt (zur Sicherheit den HMLAN sogar vom Netz
> genommen). Ergebnis: Schalten on/off geht (CUL funktioniert also) aber
> getConfig liefert auch RESPONSE_TIMEOUTS. bei einem get ... reg all sieht
> man manchmal auch peers, meistens aber nur wenige Zeilen.
>

daran arbeite ich. Es liegt daran, dass ich den HMLAN nícht verstanden
habe. Der muss mit einem eigenen Protokoll bei Laune gehalten werden.
Speziell bei langen abfragen kommt es zu Problemen.
Ausserdem muss man die Wartezeiten dynamisch machen (etwas jedenfalls) da
die Platformen unterschiedlich schnell sind und auch noch andere
Applikationen ausser HM laufen. Es muss eben echtzeit sein, so gut es geht.

>
> Mit dem CUL hat das setzen OnLevelSh zurück auf 100 auch geklappt. Aber
> erst nach 3 Versuchen, bei den ersten beiden kam NACK.
>

Siehe Oben. Ist noch nicht klar (mir) wann die devices zicken und wann
HMLAN. Ich hatte schon gesehen, dass HMLAN einfach nicht sendete... Ich
arbeite daran, kann aber dauern.

>
> Für mich jetzt kein großes Problem. Bei einer manuellen Konfiguration kann
> ich mit mehreren Versuchen leben. Wenn man es als Automatismus einsetzen
> würde, wäre es natürlich schlecht.
>

Ist klar - muss besser werden!!!

>
> Ich habe 4 gleichartige Dimmer im Haus verteilt. Von 2 Meter Entfernung
> zum HMLAN bishin zu 3 Etagen entfernt. Schalten geht immer ohne Probleme
> und dieses Konfig-Zeug ist überall gleich unzuverlässig.
>

Liegt an der menge der messages. Schalten ist nur eine Message - (fast)
kein timing zu beruecksichtigen.
Aber was,wenn einmal mehrere gleichzeitig schalten? bei deammerung, TC
melden autonom,... schwer zu testen - aber dann geht sicher schalten auch
nicht perfekt.

>
> Das also als kurze Wasserstandsmeldung!
>

danke - und mein Pegelstand zurueck.

Nebenbei, die CUL scheint aktuell stabiler zu laufen - die braucht eben
kein Protokoll. Hat aber auch noch keine komplexen Lasttests hinter sich
(mehrere devices gleichzeitig,...)


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

[Guest]

Originally posted by: <email address deleted>

wie gesagt, ich finds toll dass es überhaupt schon soweit ist! insofern ich
kann mit dem jetzigen Stand hervorragend leben. Bezüglich HMLAN sende gar
nix mehr: Ich habe auch manchmal gerade bei so Sachen wie getConfig
komplette Disconnects oder sehr selten auch Neustarts des HMLAN (dann ist
das rote Licht lange dauer-an und dann rebootet er offenbar). Ich bin mir
fast sicher, dass die FW auch Macken hat.

Immerhin ist es aber ja auch so, dass wenn der HMLAN durch rfd.exe von
einem Windows-PC bedient wird (und das ist ja auch nicht mehr oder weniger
Echtzeit als fhem) dass dann immer alles geht. Also irgendwie muss diese
rfd.exe Software "mehr wissen als wir". Was ich aber auch schon damals
mitgeloggt hatte ist, dass wenn man dann über rfd.exe mit der Software oder
direkt per XMLRPC etwas konfiguriert, dass dann auch manchmal NACKS kommen
- die rfd.exe merkt es sich dann offenbar (In der Software heisst das
"Servicemeldung") und probiert es immer mal wieder. AUch gibt es offenbar
nach jedem Schreiben in ein Gerät ein lesendes Verify. Vll haben wir es
also mit einem System zu tun, wo sicheres schreiben nur durch Auslesen und
ggf. immer wieder Ausprobieren ermöglicht wird.

VG!

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