Hallo,
so wie ich das verstehe, kann nur über das Programm "HomeMatic-Lan-Interface konfigurieren" ein Firmware Update des HM-CFG-LAN durchgeführt werden. Während "Test-Run-BidCos-Service" und "HomeMatic-Komponenten konfigurieren" beide durch Festlegung der IP-Adresse den HM-CFG-LAN "sehen", bekomme ich das Hilfsprogramm "HomeMatic-Lan-Interface konfigurieren" nicht dazu, mir den HM-CFG-LAN anzuzeigen. Der Bildschirm sieht so aus ...
(siehe Anhang / see attachement)
... und ich kann weder "Change IP Settings" noch "Update Firmware" auslösen.
Wer hat eine Tipp?
Gibt es, wie beim Hilfsprogramm "Test-Run BidCos-Service" eine Konfigurationsdatei?
Vielen Dank sagt
UFinFin
Hallo,
schon hiermit (http://forum.fhem.de/index.php?topic=10933.msg62901#msg62901)versucht?
Grüße
Arthur
Bin auch darüber gestolpert und hab für mich das Ganze protokolliert.
Schau es Dir mal an und gib Feedback...
protokolliert?
hast du mit wireshark o.ae. mitgemessen?
Gruss
Martin
nein, er hat einfach nur alle Schritte der Reihe nach aufgeschrieben. Das PDF wendet sich schon an echt Anfänger.
ja, war nur ein Versuch.
habe selbst einen update gemacht - ist immer noch die gleich FW - aber einen download hat es trotzdem gegeben...
Leider ist mir nicht klar, wo die FW her ist...
Hallo Martin,
die Firmware kommt von der Festplatte (C:\Program Files (x86)\BidCoS Service\hmlanif.enc). Bei einem Update wird die Firmware zwar an das HMLAN übertragen, der schreibt die Firmware aber nur, wenn sie neuer ist.
Anbei ein TCP-Dump von einem Update-Prozess. In diesem Fall von Version 0.961 zu 0.954 (was ja ein Downgrade währe).
Evtl. kannst du damit was anfangen.
Viele Grüße
Markus
Hallo zusammen,
hat zwar nichts mehr mit dem eigentlichen Thema (Anfrage) vom ersten Beitrag zu tun aber....
Wie man an den Mitschnitt sehen kann "sieht man nichts" - ich kann nichts Verwertbares sehen ausser Bradcasts.
Ach, ja: vielleicht könnte sich UFinFin ja wieder melden falls er/sie es geschaft hat die HMLAN in Betrieb zu nehmen.
Viele Grüße
Arthur
Hallo Arthur
ich habe es einmal bei mir probiert. Da ist schon etwas zu sehen, eigentlich der gesamte download. Der funktioniert ueber broadcasts. Und HM hat sich eine seltsame eigene IP ausgedacht.
Natuerlich sind noch einige details unklar in erster Linie: wo kommt die FW her, die geladen wird? Wenn ich die haette koennte ich einmal das decoding probieren.
Ansonsten kann man schon eine Struktur erkennen, sequenznummern,...
Der Ablauf scheint zu sein
- FW ist in der PCsw enthalten
- HM benutzt eine eigene IP adresse zum downloaden
- download und antworten werden gebroadcastet
Gruss
Martin
Hallo Martin,
wo die Firmware steckt scheint doch geklärt zu sein (Dank Markus).
Die FW verbirgt sich doch in der hmlanif.enc? Oder nicht?
Hmmm, wo die herkommt hast du doch schon beantwortet/vermutet (wird scheinbar nicht zur Laufzeit heruntergeladen - siehe Mitschintt) (ist in der Software integriert) - oder habe ich was falsch verstanden.
Ich frage mich was genau du vor hast?
- Streams/Arbeitsweise der Soft(Firm)ware herauszufinden - für was? (Sorry, kann es im Moment nicht greifen.)
- Firmwareupdate über FHEM durchführen? Ist es wirklich nötig?
- Für FHEM notwendigen Einstellungen über FHEM steuern?
Viele Grüße
Arthur
Hallo Arthur,
das Thema ging darum, wie man HMLAN updaten kann. Habe ich nicht aufgebracht... kann aber fuer FHEM interessant sein. HM arbeitet mit einer PC-SW und lädt ggf die passende FM auf den Adapter.
FHEM sollte gut daran tun mit der neusten FW zu arbeiten, erst einmal egal, wie man die auf den Adapter bringt.
Entsprechend CUL, die man auch laden kann könnte man das fuer HMLAN realisieren.
Ob es nötig ist weiss ich nicht, erst einmal wollte ich die Möglichkeiten ausloten.
HMLAN hat noch einige Probleme, mehr als die meisten user sehen. Leider habe ich keine Ahnung , wie ich an infos zur Einstellung herankomme, aber korrekt, hier ist fuer einen wirklich sauberen Betrieb noch einiges notwendig. Mit der 'besten' (letzten?) FW zu arbeiten wäre ein Versuch.
ok, die FW habe ich gefunden, da kann ich einmal abgleichen.
Gruss
Martin
Hallo Zusammen,
erstmal VIELEN DANK für die Antworten und die ausgelöste Diskussion, die eine interessanten und vielleicht sogar für FHEM zukünftig wichtig Verlauf nimmt.
Zweitens: ENTSCHULDIGUNG, weil diese Rückantwort doch etwas auf sich warten lies.
Drittens: Ich habe es hinbekommen, wobei die Summe an Antworten mich auf den für meine Konstellation richtigen Weg gebracht hat.
Nach genauer Fehleranalyse liegt der Grund, dass "HomeMatic-Lan-Interface konfigurieren" den HM-CFG-LAN nicht "sah", an der Programmierung, die mit mehreren Netzwerkadaptern meines Windows 7 Rechners nicht klar kam.
Nachdem ich den Hinweis "Alle Netzwerkadapter deaktivieren, die nicht benötigt werden" durchgeführt habe, fand "HomeMatic-Lan-Interface konfigurieren" meinen HM-CFG-LAN immer noch nicht:
(siehe Anhang / see attachement)
Nun hat mein Mainboard ZWEI physische LAN Anschlüsse und ich verwende aus historischen Gründen Netzwerkadapter "LAN-Verbindung 2". Auf der Suche nach dem Fehler habe ich daraufhin das Netzwerkkabel zum Router in den anderen LAN Anschluss gesteckt, "LAN-Verbindung" aktiviert und "LAN-Verbindung 2" deaktiviert. Und siehe da:
"HomeMatic-Lan-Interface konfigurieren" sieht dem am Router angehängten HM-CFG-LAN sofort!
Also konkretisiere ich die Handlungsanweisung (passend zu meiner Konfiguration und ohne Anspruch, dass es nicht auch anderes geht):
1.) Schließe das Netzwerkkabel zum Router an den "ersten" LAN-Netzwerkadapter an, sofern das Mainboard mehrere Netzwerkanschlusse besitzt.
2.) Deaktiviere alle anderen Netzwerkadapter, außer dem, der zum ersten LAN-Netzwerkadapter gehört.
3.) Starte das Programm "HomeMatic-Lan-Interface konfigurieren".
4.) Sofern das HM-CFG-LAN angezeigt wird, kann ein Firmware-Update durchgeführt werden.
Gleichzeitig mit diesem Beitrag habe ich den Software-Hersteller mit der Bitte angeschrieben, diesen Fehler zu beheben (oder ggf. den Quellcode des Tools zur Verfügung zu stellen - Prinzip Hoffnung).
Mal sehen, was passiert.
Viele Grüße und einen schönen Restsonntag wünscht
UFinFin
Hallo Martin,
schon mal in die Verzeichnisse:
"C:\Program Files (x86)\BidCoS Service\sample_config"
und
"C:\Program Files (x86)\BidCoS Service\devicetypes"
geschaut, hier befinden sich diverse XML Dateien die vielleicht nicht ganz uninteressant sind - aber bestimmt kennst du sie schon.
Zwischendurch (Sicher nicht mal eben kurz beantwortet - würde mich dennoch interessieren): Woher weiß eigentlich ein(e) HMLAN wie er mit den entsprechenden Devices sprechen soll (sofern Devices direkt mit CUL gepairt sind) "klar über die Firmware ;o) ", werden die XML Files aus den Verzeichnis C:\Program Files (x86)\BidCoS Service\devicetypes hochgeladen (beim Firmwareupdate)?
Ich denke aber eher, dass die PC APP diese files nutzt.
Was mir noch aufgefallen ist es existiert ein Dienst Namens "Bidcos-Service" seine funktion mir noch nicht klar ist?
Vielleicht hat dieser was mit dem Problem was UFinFin (Alle anderen User inkl. meiner wenigkeit) hatte zu tun und etwas mit dem Eintrag in der Config (bidcos.conf) - scheint aber ein Beispiel zu sein wo sie tatsächlich liegt siehe weiter unten!)###########################################################
[Interface 0]
Type = Lan Interface
Serial Number = ABC0000001
# The encryption key is found on a sticker on the lan interface
Encryption Key = 12345678901234567890123456789012
Description = First Lan Interface
# IP Addess is optional. If not specified, the Lan Interface is
# detected by its serial number.
# You may have to use the IP address if your lan interface is behind a
# router or a firewall.
#IP Address = 192.168.1.195
###########################################################
Diese Datei liegt auch unter "C:\ProgramData\Bidcos-Service"
Hier liegen auch die Logs (Verzeichnis "log") die der Bidcos-Service (Dienstname: BidCoS-Service | Command: C:\Program Files (x86)\BidCoS Service\rfd.exe -d)
In den entsprechenden Logs sieht man folgende Einträge:
10.03.2013 10:52:33 <Info> BidCoS-Service started
10.03.2013 10:52:33 <Info> XmlRpc Server is listening on TCP port 2001
10.03.2013 10:52:33 <Debug> Default interface is now ABC0000001
10.03.2013 10:52:33 <Info> Current AES key=1, previous AES key=0
10.03.2013 10:52:33 <Error> ABC0000001: Could not determine IP
10.03.2013 10:52:33 <Error> ABC0000002: Could not determine IP
10.03.2013 10:52:33 <Error> Data interface config_string not supported
10.03.2013 10:52:33 <Error> <paramset id="remote4dis_ch_master"> could not initialize parameter
10.03.2013 10:52:33 <Warning> rf_4dis.xml: error parsing file
10.03.2013 10:52:33 <Debug> Device description rf_ash550.xml loaded (1)
10.03.2013 10:52:33 <Debug> Device description rf_bl.xml loaded (2)
.......
10.03.2013 10:52:33 <Debug> Device description rf_winmatic.xml loaded (41)
10.03.2013 10:52:33 <Debug> Device description rf_ws550.xml loaded (42)
10.03.2013 10:52:48 <Error> ABC0000002: Could not determine IP
......
10.03.2013 10:57:50 <Error> ABC0000001: Could not determine IP
10.03.2013 10:58:22 <Info> BidCoS-Service started
10.03.2013 10:58:22 <Info> XmlRpc Server is listening on TCP port 2001
10.03.2013 10:58:22 <Debug> Default interface is now ABC0000001
10.03.2013 10:58:22 <Info> Current AES key=1, previous AES key=0
10.03.2013 10:58:22 <Error> Data interface config_string not supported
10.03.2013 10:58:22 <Error> ABC0000001: Could not determine IP
10.03.2013 10:58:22 <Error> ABC0000002: Could not determine IP
10.03.2013 10:58:22 <Error> <paramset id="remote4dis_ch_master"> could not initialize parameter
10.03.2013 10:58:22 <Warning> rf_4dis.xml: error parsing file
Solche Meldungen erzeugt der Dienst regelmässig.
Gruß
Arthur
Hallo Arthur,
danke, die XML files lade ich alle Zeit von EQ3. Die sind dort im Image enthalten.
Daher kenne ich die Register. Leider sind die Files nicht vollstaendig bezüglich der messages... aber sehr hilfreich.
Die CUL ist komplett transparent, es wird einfach alles gesendet, was man reinschiebt - und alles an FHEM durchgereicht, was aus der Luft gefischt wird.
HMLAN ist prinzipiell ähnlich, macht aber mehr. Sendet acks, verwaltet einzelne IDs intern...
Generell muss das IO device nicht wissen, an wen es sendet, warum auch (siehe CUL). Die Luft ist ein 'bus' alle hören mit, jeder filtert selbst nach seiner Adresse.
FHEM nutzt die XML Files nicht, EQ3 sicher.
Das Problem von UFinFin war doch seinen 2 LAN interfaces und der damit kommenden fehl-einstellung geschuldet. Dein Problem kenne ich jetzt nicht. Was ist das Problem?
ist dein Problem, dass die eQ3 SW die IP adresse nicht findet?
10.03.2013 10:52:33 <Error> ABC0000001: Could not determine IP
da kann ich wenig helfen
Gruss
Martin
Hallo Martin,
sorry, mit CUL habe ich CUL_HM gemeint - aber soweit verstanden - danke.
Das n Network Interfaces Problem hatte ich auch daher der Versuch hier weiter zu helfen - zufälligerweise auf den Dienst gestoßen der seinen Dienst nicht verrichtet (laut Log) und dabei eben auf die XMLs gestossen.
Bei mir läuft soweit alles - ich habe derzeit diesbezüglich keine offene Themen - wie ich verstanden habe UFinFin auch nicht -> Thread zu?!.
Viele Grüße
Arthur
EDIT: sorry, mit CUL habe ich HMLAN gemeint - aber soweit verstanden - danke.