Frage zu CUL_HM regSet & Co

[Guest]

Originally posted by: <email address deleted>

Am Samstag, 10. November 2012 20:39:41 UTC+1 schrieb unimatrix:
>
> 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.
>

Sicher ist, das es diese '+-' messages gibt - und mehr - mit denen in
irgendeiner Form ein queue-handling erfolgt. Auch timing ist wichtig, habe
da schon etwas.

>
> 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.

Das wird aber nicht aus  HMLAN getriggert- oder? werde ich einmal testen.
Wenn das Protokoll einmal sauber(er) funktioniert kann ich auch einmal
ueber verify nachdenken und einen save/restoreconfig machanismus eines
Device
 

> Vll haben wir es also mit einem System zu tun, wo sicheres schreiben nur
> durch Auslesen und ggf. immer wieder Ausprobieren ermöglicht wird.
>
wenn HMLAN besser funktioniert...  

>
> VG!
>

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

[Guest]

Originally posted by: <email address deleted>

Nein, das HMLAN macht das Queuing auf keinen Fall selbst. Die ganze
Intelligenz ist in der rfd.exe also in der Windows-Software. Das ist ja die
gleiche Software die auch als Abstraktions-Layer auf einer CCU läuft und
die dann die XMLRPC Schnittstelle zur Verfügung stellt.

Ich bin mir sehr sicher, dass der HMLAN bis auf Ausnahmen dumm ist

Ich habe noch eine CCU in der Schublade die ich nicht mehr benutze. Wollte
sie längst über Ebay loswerden war aber immer zu faul und dachte mir "vll.
braucht man sie nochmal". Ich könnte Sie dir leihweise zuschicken wenn das
das Testen irgendwie erleichtern sollte. Man kann sicherlich gut mitloggen,
wie die CCU das alles so macht. Ich selber bin bis Jahresende nur noch
wenige Tage zu Hause daher kann ich das im Moment nicht selbst anbieten.

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

[Guest]

Originally posted by: <email address deleted>

Am Sonntag, 11. November 2012 10:02:58 UTC+1 schrieb unimatrix:
>
> Nein, das HMLAN macht das Queuing auf keinen Fall selbst. Die ganze
> Intelligenz ist in der rfd.exe also in der Windows-Software. Das ist ja die
> gleiche Software die auch als Abstraktions-Layer auf einer CCU läuft und
> die dann die XMLRPC Schnittstelle zur Verfügung stellt.
>
> Ich bin mir sehr sicher, dass der HMLAN bis auf Ausnahmen dumm ist
>
nicht ganz. Ich bin mir sicher, dass HMLAN ggf ACKs schickt, messages
wiederholt, nachrichten manchmal nicht mehr sendet.  
Ausserdem muss man ihn bei laune Halten ueber diverse nebenmessages.
Den Process will ich jetzt verstehen.
CUL ist "sehr" transparent

>
> Ich habe noch eine CCU in der Schublade die ich nicht mehr benutze. Wollte
> sie längst über Ebay loswerden war aber immer zu faul und dachte mir "vll.
> braucht man sie nochmal". Ich könnte Sie dir leihweise zuschicken wenn das
> das Testen irgendwie erleichtern sollte. Man kann sicherlich gut mitloggen,
> wie die CCU das alles so macht. Ich selber bin bis Jahresende nur noch
> wenige Tage zu Hause daher kann ich das im Moment nicht selbst anbieten.
>
Danke fuers Angebot - ich messe ersteinmal das HMLAN verhalten aus - dann
sehe ich weiter
 

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

[Guest]

Originally posted by: <email address deleted>

Danke für das PDF, schaue ich mir mal in Ruhe an!

Die anderen Sachen funktionieren bei mir allerdings auch alle nicht. Vll.
liegts ja am HMLAN. Bin jetzt nicht zu Hause und kann daher jetzt nicht mit
CUL testen.

Ich habe meine 3 Dimmer durchprobiert. Sowohl mit 4 byte als auch mit Namen
als auch mit self, self1, self2 etc. kommt immer ein NACK.

Ein getConfig führt immer zu mehreren RESPONSE_TIMEOUTs und dann hat man
ein Subset der Infos eingelesen, teilweise fehlen Peers. Außerdem sieht man
im Log dass beim getConfig auch schonmal die Verbindung zum hmlan ganz
getrennt wird und dann wieder hergestellt wird.  (der FHEM-Rechner ist über
CAT7 Kabel und Gigabit-Switch am HMLAN...)

ein get dim_flur reg all zeigt auch, dass meine Werte tatsächlich nie in
den Devices ankaman.

Das alles nur als Hinweis...der hmlan scheint doch böse zu sein...der
einzige Grund, dass ich ihn nutze ist der, dass ich an dem Einsatzort mit
der besten Funkabdeckung keinen Always-On-Rechner stehen habe für den
CUL-Stick.



Am Freitag, 9. November 2012 12:08:39 UTC+1 schrieb Martin:
>
>
>
>> 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>

Ich finde das PDF übrigens hervorragend. Vor allem die Beschreibung der
Jump-Tabellen usw. Das hat selbst EQ3 noch nie beschrieben und das
Verständnis hilft jedem Anwender von HM, selbst wenn er kein FHEM sondern
die CCU einsetzt (um dort das richtig zu konfigurieren, muss man es nämlich
auch verstehen, den "Expertenmodus").

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 ...

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

VG

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