HMLAN ID

stgeran · 22 April 2013, 22:50:04

Wenn ich z.B. <attr HMLAN1 hmId 7588B1> eingebe, habe ich im logfile <HMLAN setting owner to 7588B1 from 758CB7>. 758CB7 ändert sich jedes mal. Ist das richtig? Warum behält der HMLAN nicht seine zugewiesene Adresse?

martinp876 · 23 April 2013, 07:07:42

hast du schon einmal 'save' gemacht nach der aenderung?

stgeran · 23 April 2013, 20:00:26

Du meinst <save config>?? Ja, hab ich. Und jedes mal neu im log von xxxxx zu meinem in der cfg eingegebenen Wert. Nur zum Verständnis: der Wert xxxxx ist jedesmal ein anderer.

martinp876 · 24 April 2013, 08:46:55

muss ich bei meinem einmal aufpassen.
Also in deinem fhem.cfg steht ein
attr HMLAN1 hmId 7588B1

damit muesste in jeden Fall nach dem restart der richtige Wert gesetzt werden, automatisch.
Bleibt die Frage warum der wert im HMLAN nicht stehen bleibt. Wenn du den HMLAN einmal stromlos machst,wird dann der wert noch einmal gesetzt?

stgeran · 24 April 2013, 17:38:48

Hab ich probiert: the same procedere as every year < HMLAN setting owner to 7588B1 from 77F49B>
Er setzt sich zwar immer auf meine in der cfg angegebene Nummer, aber immer von einer anderen Ausgangsbasis. Diesmal halt 77F49B.

Zrrronggg! · 26 April 2013, 22:41:11

Macht meiner auch.

Ich mein irgendwo gelesen zu haben, dass der HM-LAN sich im Moment des ersten Kontakts mit einem "Host" selber eine zufällige ID vergibt. D.H. sobald FHEM
Opening HMLAN1 device IP:1000
macht, setzt sich der HMlan eine eigene zufällige ID und die wird dann kurz da nach auf die eingestellte geändert.

Das ist bestimmt dazu gedacht um IDkonflikte beim Einsatz von mehreren HMLANs zu vermeiden.

mgernoth · 29 Mai 2013, 08:27:02

Hallo,

anscheinend versucht fhem die ID beim starten zu setzen und bekommt einen ungültigen Wert aus dem hmId-Attribut. Wie das sein kann, ist mir allerdings schleierhaft, da das ja eigentlich undef sein sollte...

Ich bin gerade dabei einen HMLAN zu emulieren (dazu später in einem neuen Thread mehr, wenn es komplett funktioniert) und bin beim Debuggen auf folgende Sequenz direkt nacht dem fhem-Start gestossen:

Code Auswählen


$ socat -v -x TCP4-LISTEN:1234,reuseaddr EXEC:./hmland,pty
> 2013/05/29 08:04:44.267847  length=9 from=0 to=8
 41 41 35 39 41 43 44 0d 0a                       AA59ACD..
--
> 2013/05/29 08:04:44.268351  length=3 from=9 to=11
 43 0d 0a                                         C..
--
> 2013/05/29 08:04:44.268859  length=18 from=12 to=29
 59 30 31 2c 30 31 2c 0d 0a                       Y01,01,..
 59 30 32 2c 30 30 2c 0d 0a                       Y02,00,..
--
> 2013/05/29 08:04:44.269302  length=18 from=30 to=47
 59 30 33 2c 30 30 2c 0d 0a                       Y03,00,..
 59 30 33 2c 30 30 2c 0d 0a                       Y03,00,..
--
> 2013/05/29 08:04:44.269964  length=26 from=48 to=73
 54 31 39 33 38 35 36 46 43 2c 30 34 2c 30 30 2c  T193856FC,04,00,
 30 30 30 30 30 30 30 30 0d 0a                    00000000..
--
< 2013/05/29 08:04:44.302890  length=56 from=88 to=143
 48 48 4d 2d 4c 41 4e 2d 49 46 2c 30 33 42 43 2c  HHM-LAN-IF,03BC,
 4a 45 51 30 35 33 35 31 32 32 2c 31 44 42 31 35  JEQ0535122,1DB15
 35 2c 41 35 39 41 39 41 2c 30 30 30 37 36 39 45  5,A59A9A,000769E
 35 2c 30 30 30 30 0d 0a                          5,0000..
--
"HMLAN" antwortet mit 4 mal I...
--
> 2013/05/29 08:04:45.050545  length=9 from=74 to=82
 41 31 31 32 32 33 33 0d 0a                       A112233..

Die zuerst gesetzte hmId "A59ACD" ändert sich bei jedem Neustart (die "A59A9A" stammt z.B. vom letzten fhem-Start).
Kann das Problem evtl. daran liegen, dass der HMLAN (bzw. bei mir die HMLAN-Emulation) nicht sofort nach dem Verbindungsaufbau mit dem Banner antwortet und deshalb fhem nicht weiss, welche ID gesetzt ist? Ich hab mich jetzt allerdings nicht direkt zwischen fhem und einen echten HMLAN gehängt um zu sehen, ob das Timing das Problem ist.

Der hmlan ist folgendermaßen definiert:

Code Auswählen


define hmlan HMLAN 127.0.0.1:1234
attr hmlan hmId 112233
attr hmlan respTime 3

Habe gerade leider keine Zeit den genauen Grund zu suchen (deswegen nur meine Vermutung oben), komme frühestens heute Abend dazu.

Gruß
Michael

martinp876 · 29 Mai 2013, 08:56:36

Hi,

HMLAN emulation? Bin gespannt auf Zweck, Funktion und Implementierung.

ist mir auch unklar woher die erste HMID kommt. Wie testest du? FHEM restart oder HMLAN stromlos?

mgernoth · 29 Mai 2013, 10:11:51

Hi,

Zitat von: martinp876 schrieb am Mi, 29 Mai 2013 08:56HMLAN emulation? Bin gespannt auf Zweck, Funktion und Implementierung.

Zweck ist es, den günstigen HM-CFG-USB{,2} einfach in fhem benutzen zu können. Zumindest hatte ich diesen Plan gestern Abend und bin soweit gekommen, dass die Emulation meine Schreibtischlampe steuern konnte. :-)
Implementiert ist das ganze in C und benutzt die libusb-1.0, sollte also auch z.B. einen kleinen OpenWRT-Router mit USB in einen HMLAN verwandeln können.

Es gibt aber noch ein bisschen was zu tun, bis ich die Emulation veröffentliche (native Socket-Schnittstelle ohne socat, besseres Parsing der Anfragen/Antworten, ...).

Gekauft hatte ich mir den HM-CFG-USB2 eigentlich, um die ASE-Signierung auseinander zu nehmen...

Zitatist mir auch unklar woher die erste HMID kommt.

Evtl. funktioniert "undef" nicht mit AttrVal? Hab in die fhem-Internas noch keinen richtigen Einblick...

ZitatWie testest du? FHEM restart oder HMLAN stromlos?

Das setzen der falschen ID passiert bei mir nur das erste mal nach einem fhem-Neustart. Bei laufendem fhem und einem Neustart der Emulation wird gleich die richtige ID gesetzt:

Code Auswählen


$ socat -v -x TCP4-LISTEN:1234,reuseaddr EXEC:./hmland,pty
> 2013/05/29 10:06:26.011177  length=9 from=0 to=8
 41 31 31 32 32 33 33 0d 0a                       A112233..
...

Gruß
Michael

martinp876 · 29 Mai 2013, 10:22:31

ZitatEvtl. funktioniert "undef" nicht mit AttrVal? Hab in die fhem-Internas noch keinen richtigen Einblick...

moeglich - aber wenn ein Zufallswert zurueckgeliefert werden sollte, warum einer der aussieht wie eine HMID?

Ich werde es einmal testen.

mgernoth · 29 Mai 2013, 10:47:02

Hallo Martin,

Zitat von: martinp876 schrieb am Mi, 29 Mai 2013 10:22moeglich - aber wenn ein Zufallswert zurueckgeliefert werden sollte, warum einer der aussieht wie eine HMID?

Ja, stimmt. Das wäre sehr unwahrscheinlich.

Die Lösung ist (wie immer) deutlich logischer und findet sich in Zeile 63 von 00_HMLAN.pm (HMLAN_Define):

Code Auswählen


  $attr{$name}{hmId} = sprintf("%06X", time() % 0xffffff); # Will be overwritten

Gruß
Michael

martinp876 · 29 Mai 2013, 11:23:30

danke - zu einfach...

mgernoth · 01 Juni 2013, 13:48:29

Hallo Martin,

spricht etwas dagegen, die Zeile einfach komplett zu entfernen? (Habe angehängten Patch hier ohne negative Folgen am laufen)
Damit fällt das Setzen der falschen hmId beim Fhem-Start weg, und das EEPROM des HMLAN wird geschont (jede hmId-Änderung wird da ja abgelegt).

Gruß
Michael

martinp876 · 01 Juni 2013, 20:11:39

Hallo Michael,

Du hast recht.
Die Eigenart von FHEM ist, dass erst das Device definiert und hochgefahren wird und erst dann die Attribute kommen.
Ein Sonderfall waere, wenn das attribut hmid nicht gesetzt wurde.
Ich werde dann (Zeile 369) einbauen, wenn keine hmid gesetzt ist, dass das Attribut mit der vom HMLAN gemeldeten beschrieben wird. Der User kann es dann immer noch aendern.

Einverstanden?

Gruss
Martin

mgernoth · 01 Juni 2013, 20:42:46

Hallo Martin,

ja, das hört sich sinnvoll an.

Gibt es die Möglichkeit, dass HMLAN_Parse aufgerufen wird, bevor die Attribute gefüllt sind?

Und wird beim Füllen der Attribute ein schon existierendes Attribut immer mit dem Benutzerwert überschrieben (so scheint es zu sein)?
Falls letzteres der Fall ist, muss man sich um die erste Frage keine Gedanken machen ;-)

Danke & Gruß
Michael