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?
hast du schon einmal 'save' gemacht nach der aenderung?
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.
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?
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.
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.
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:
$ 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:
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
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?
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:
$ 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
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.
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):
$attr{$name}{hmId} = sprintf("%06X", time() % 0xffffff); # Will be overwritten
Gruß
Michael
danke - zu einfach...
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
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
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
Hallo Michael,
FHEM laeuft schon los bevor die Attribute aus config komplett sind. Daher kann auch parse schon kommen, bevor wir 'komplett' sind. Das ist es ja, was du gefunden hast.
Ich werde also das Attribut setzen, wenn es noch leer ist und wenn HMLAN eins rückmeldet. Somit muesste der User eigentlich hmid des HMLAN nicht mehr setzen...
Gruß Martin
> FHEM laeuft schon los bevor die Attribute aus config komplett sind.
> Daher kann auch parse schon kommen, bevor wir 'komplett' sind.
Nein, bzw. das wuerde mich stark wundern.
Hi Rudi,
Hast du recht, Parse kommt nicht dran.
HMLAN sendete aber schon, eben die HMId (ohne sie zu kennen). Die Antwort darauf kommt dann später und wird erst geparst, wenn das Attribut aus fhem.cfg gesetzt ist.
Sollte es nicht von User gesetzt sein, wird der Wert des HMLAN genommen.
Der neuen Implementierung sollte es hiermit egal sein.
Korrekt waere es, dass OpenDev erst auszuführen, wenn alle Attribute bekannt sind.
In diesen Zusammenhang gibt es evtl. auch Probleme mit den hmKey, der wohl auch notwendig ist, aber noch nicht bekannt....
Danke Martin
> Korrekt waere es, dass OpenDev erst auszuführen, wenn alle Attribute bekannt sind.
get auch, da gibt es sogar mehrere moeglichkeiten:
- NotifyFn anlegen, hier auf global:INITIALIZED hoeren, Initialisierung durchfuehren (funktioniert nur fuer fhem.cfg gut)
- Im AttrFn die Initialisierung durchfuehren (mein Favorit, da es auch im Online-Fall funktioniert).
- Den Wert nicht als Attribut, sondern als Argument von define angeben.
Hallo Rudi,
danke.
global INITIALIZED habe ich noch nicht verwendet, waere fuer Open Dev sicher die korrekte Lösung.
attrFn nutze ich schon an einigen Stellen. Hier (hmId) ist es nicht notwendig, da es sowieso alle 25sec geprüft wird.
Den Wert in das Define einbauen wuerde Sinn machen. Aber jemand vor mir hat sich anders entschieden. Es jetzt zu aendern wuerde User unnötig aergern.
In Sachen 'Key' werde ich wohl ggf ein AttrFn einbauen, hier bin ich aber mit den Tests immer vorsichtig, da ich es schlecht prüfen kann. Bisher gibt es keine Beschwerden.
Gruss Martin