Hallo zusammen,
ich habe mir sehr günsitg ein Internetkommunikationsmodul als defekt
geschossen. Dieses versuche ich jetzt in Gang zu bekommen. Ausgangslage
und während des Verkaufs geschilderte Problkematik waren, dass das Modul
sich nicht mit der App verbindet. Dieses glit via LAN als auch WLAN.
Nach dem Abarbeiten der Aktivierungsreihenfolge -anschließen des VR920
mit EBus und Ethernet LAN, Einstecken des Netzteils des VR920 und nach
einiger Zeit einschalten der Heizung- passiert nichts. Die LED im VR920
leuchtet Rot (Laut Anleitung heisst das, dass Verbindung zum Internet
bestand, jedoch abgebrochen wurde). Via Ebus wird das Vr920 nicht im
VRC700 als "Regelermodul" erkannt (Wobei ich nicht weiss ob das dort
aufgeführt werden muss).
Folgendes habe ich daraufhin probiert:
Ich habe das Modul via Ethernet direkt mit meinem PC vergbunden und den
Datenverkehr nach dem Einschlaten des Moduls mitgeschnitten. Dieses
Protokoll hänge ich mal hier an, vielleicht erkennt ja einer etwas
daraus. Aus meiner Sicht scheint kein aktiver Datenverkehr aus dem VR920
herauszugehen.
Meine Frage wäre jetzt, ob irgendwelche firmeninternen resetvorgänge für
das Modul bekannt sind, damit ich "neu anfangen" kann. Das VR920 hat
offiziell kein reset knopf mehr. In der Anleitung wird der mit einer
Büroklammer oder ähnlichen Gegenstand zu drückende Knopf als
Entstörknopf betitelt. Diesen habe ich auch schon genutzt, auch habe ich
den mal eine Minute lang gedrückt. Es passierte leider nichts. Zudem
möchte ich auch noch auf ein Recherche-ergebnis im Internet aufmerksam
machen: Es wird in einem Forum kurz angegeben, dass wenn der VR920 nicht
innehralb von fünf Tagen nach Stromanschluss aktiviert wird, sich nicht
mehr aktivieren lässt. Ist einem bekannt wie man das umgehen kann?
Ich weiss dass das einer Suche nach einer Nadel im Heuhaufenm gleicht,
doch wenn jemand Methoden oder Vorschläge hat sich einer möglichen
Lösung anzunähern, immer her damit. Vielleicht ists auch möglich unter
Verwendung der seriellen Schnittlstelle (UART-Schnittstelle) X10 mit
RS232 etwas zu reißen/auszulesen
Vielen Dank euch schonmal
Hast du schonmal auf den Ebus geschaut, ob sich da was tut?
Gibt da einen Ebus Deamon von für z.b. einen Raspberry Pi:
https://github.com/john30/ebusd
Dann braucht man noch ein Ebus-Interface, was man sich auch selbst bauen
kann:
https://adapter.ebusd.eu/
Ich hab noch ein altes ohne Interface USB <-> Ebus, das könnte ich dir
ausleihen.
Vielen Dank für das Angebot, aber ich weiß nicht ob mich das weiter
bringt. Ich Denke mein erstes Ziel wäre zu gucken wie ich den Ethernet
Anschluss zum laufen bekomme um damit Zugriff auf die
Bedienungsoberfläche des Kommunikationsinterface zu bekommen.
Obwohl die Ethernet LEDs ab und zu blinken, sowie am PC als auch am
Kommunikationsmodul, muss ja irgendetwas gesendet oder empfangen werden.
Dem Wireshark Protokoll nach ist aber nichts vom Kommunikationsmodul zu
entnehmen. Sondern nur Anfragen von meinem PC mit APIPA Adresse. Aus dem
Protokoll lese ich keine MAC Adresse raus, als auch keine IP Adresse vom
Modul. Das macht mich stutzig, es muss doch irgendwie möglich sein an
die Mac Adresse zu kommen. Und dann vielleicht darauf basierend eine IP
Adresse zu zu weisen.
Das wären so meine Gedankengänge.
Sebastian D. schrieb:> Sondern nur Anfragen von meinem PC mit APIPA Adresse.
Ist das nur ein Netzwerk zwischen PC und dem Board? Hänge das mal an
einen Router oder starte einen DHCP Server.
Schon gemacht, der DHCP Vorgang macht keinen unterschied. Zudem sendet
der PC auch broadcast Anfragen die augenscheinlich keine Beachtung
finden. Das Modul gibt keinen Mucks.
Dann belausche mal die Signale dieser beiden Anschlüsse. Ich meine den 3
oder 6 Pin Anschluss an der Platinenseite und den 10 Pin Anschluss.
Und zwar direkt wenn du der Platine Strom gibst.
Du suchst dir also einen Masseanschluss für die Oszimasse und dann gehst
du mit dem Oszitastkopf von Anschluss zu Anschluss.
Stellst auf Normal Trigger und z. B. 1V. Und dann gibst du der Platine
Strom. Wenn da nix triggert Strom weg, zum nächsten Pin, Trigger
scharfschalten und Strom ran an die Platine.
Irgendwo wirst du einen UART TX finden. Wenn du den hast kannst du
Baudrate messen und einen UART Adapter anschließen um den ausgegebenen
Text zu sehen.
Gustl schrieb:> Ui gugge mal, das findet man wenn man nach dem Modell sucht:> https://forum.fhem.de/index.php?topic=57815.15
Der Eintrag ist mir bekannt jedoch komme ich über dieses Thema nicht auf
mein Problem.
Zum ersten verwundert mich, dass auf dem EthernetAnschluss KEINE
Bewegung ist.
Zum zweiten versuche ich ja primär das Teil zu resetten und zum
neubooten zu bewegen.
Ob das alles so geht, weiss ich nicht, müsste doch aber aus meiner Sicht
irgendwie möglich sein. Es sei denn es ist Hardwaremäßig vollständig
defekt, was ich aber nicht glaube. Zumindest eine Sichtprüfung
untermauert dies zunächst.
H. H. schrieb:> Sebastian D. schrieb:>>> Zumindest eine Sichtprüfung>> untermauert dies zunächst.>> Bei BGA wenig sinnvoll.
Ich sach ja, … zunächst… eine verkohlte Stelle auf der Platine ist für
mich leicht zu erkennen. Aber auch nur weil ich Hobbygriller bin ;)
Hello,
I would like to reopen the discussion because I currently have the same
problem with the red light.
Did you manage to solve your problem?
Thanks
Guten Morgen in die Runde,
ich weiss, der Beitrag ist schon was her, doch ich meine, ich bin der Sache etwas näher gekommen.
Ich habe es geschafft Zugang zu diesem Mikrocontroller über die Programmierschnittstelle zu bekommen, stehe aber jetzt Softwareseitig vor dem nächsten Rätsel.Via eines USB Seriell Konverters konnte ich die folgende automatisierierte NAchricht auslesen:
1
U-Boot 2014.10-rc2 (Sep 26 2017 - 14:50:18)
2
3
CPU: Freescale i.MX6SOLO rev1.3 at 792 MHz
4
Reset cause: WDOG
5
Board: Vaillant comDialog/2
6
Watchdog enabled
7
I2C: ready
8
DRAM: 512 MiB
9
MMC: FSL_SDHC: 0
10
In: serial
11
Out: serial
12
Err: serial
13
Net: FEC [PRIME]
14
Hit any key to stop autoboot: 0
15
Saving Environment to MMC...
16
Writing to MMC(0)... done
17
gpio: pin 125 (gpio 125) value is 0
18
gpio: pin 17 (gpio 17) value is 0
19
gpio: pin 126 (gpio 126) value is 0
20
gpio: pin 125 (gpio 125) value is 1
21
gpio: pin 126 (gpio 126) value is 1
22
gpio: pin 125 (gpio 125) value is 0
23
gpio: pin 17 (gpio 17) value is 0
24
gpio: pin 126 (gpio 126) value is 0
25
gpio: pin 125 (gpio 125) value is 1
26
gpio: pin 126 (gpio 126) value is 1
27
Maximum reboot count exceeded.
28
gpio: pin 125 (gpio 125) value is 0
29
gpio: pin 17 (gpio 17) value is 0
30
gpio: pin 126 (gpio 126) value is 0
31
gpio: pin 125 (gpio 125) value is 1
32
sleep - delay execution for some time
33
34
Usage:
35
sleep N
36
- delay execution for N seconds (N is _decimal_ !!!)
U-Boot kommt nicht weiter weil es das eigentliche OS nicht booten kann. Man wird also wohl die Software neu aufspielen müssen (unter der Voraussetzung dass der Flash noch in Ordnung ist). Das kann man über U-Boot machen, man braucht aber die Software/Image des OS.
mitlerweile habe ich auch folgendes herausgefunden, nachdem ich abwechslungsweise ein intaktes Ethernetkabel genommen habe :/ . Jetzt bekommt laut Konsole das Gerät auch eine IP Adresse. Seit dem versucht er dauerhaft folgendes
DHCP client bound to address 192.168.XXX.137 (27 ms)
45
*** Warning: no boot file name; using 'C0A82E89.img'
46
Using FEC device
47
TFTP from server 192.168.XXX.1; our IP address is 192.168.XXX.137
48
Filename 'C0A82E89.img'.
49
Load address: 0x12000000
50
Loading: T T T T T T T T T T
51
Retry count exceeded; starting again
Fällt jemandem dazu etwas ein?
Was ja ersichtlich ist, er versucht vom TFTP Server 192.168......, sprich meinem Gateway eine Datei herunter zu laden. Bekommt aber augenscheinlich keine Verbindung. Ich stelle mir jetzt die Frage, warum von meinem Gateway? Normalerweise müsste da doch eine IP Adresse eine FTP Servers sein? Könnte man die IP des TFTP Servers heruasfinden und eintragen?
Für Ideen uder Interpretationen bin ich sehr dankbar. :)
Und mit LAN Verbindung versucht es U-Boot dann halt per TFTP um an ein gültiges Image zu kommen, das wird so konfiguriert sein. Das ändert nichts daran dass man das OS Image braucht um weiterzukommen.
Alternativ könnte man den kompletten Flash auslesen und schauen ob man eventuell das beschädigte Image im Flash reparieren kann.
Warum sucht er die Datei in einem lokalen Netzwerk? Müsste er nicht auf einen FTP Server von Vaillant zugreifen, mit öffentlicher IP? Warum im Gateway?
Warum sucht er die Datei in einem lokalen Netzwerk? Müsste er nicht auf
einen FTP Server von Vaillant zugreifen, mit öffentlicher IP? Warum im
Gateway?
Das ist lediglich für die Entwicklung gedacht um die Software neu aufzuspielen (im lokalen Netz). Niemand wird ernsthaft TFTP über das öffentliche Internet verwenden um ein Software Update durchzuführen.
Mit "printenv" kann man die Konfiguration anzeigen lassen, dann sollte man sehen wie das genau gedacht ist.
set_systemd_target=if test ${var03_pin} -eq 0;then run set_target_to_vr900;else if test ${var02_pin} -eq 0;then if test ${is_not_eol_pin} -eq 0;then run set_target_to_eol;else run set_target_to_vr920;fi;else if test ${is_not_eol_pin} -eq 0;then run set_target_to_eol_wo_cc1310;else run set_target_to_vr920_wo_cc1310;fi;fi;fi;
Du könntest noch ein paar weitere Kommandos ausprobieren die zusätzliche Informationen liefern:
1
mmcinfo
2
3
mmc
4
5
help mmc
6
7
mmc dev 0
8
mmc rescan
Das Auslesen des Flash läuft vermulich darauf hinaus dass man mit den Kommandos des "MMC sub system" Teile des Flash in den RAM liest und diese dann per "md.b" als Hexdump über die Konsole ausgibt. Die Ausgabe schneidet man mit, den Dump kann man dann am Ende in binäre Dateien umwandeln. Eventuell gibt es Alternativen die schneller sind aber im moment sehe ich keine.
" [...] Energieinformationen aus den Vorgänger-Apps aber nicht mehr möglich ist.
Sollte Ihre Internet-Kommunikations-Box schont seit längerem offline sein und nicht bis zum 29.03.2024 für mind. 24 Stunden online gehen und Sie ihre Anlage nach dem 01.04.2024 wieder per App steuern wollen, ist eine kostenpflichtige Neuschaffung einer aktuellen Internet-Kommunikations-Box (VR-940f) notwendig."
Selbst wenn ich es schaffen sollte Daten zu retten und es zum Laufen zu bekommen, kann das Teil sowiseo nicht wie gewünscht integriert werden. War mir bisher so nicht klar. Schade eigentlich. Immerhin habe ich dafür einen "Defekt-Preis" bezahlt.
Ja, das ist in der Tat nicht sehr kundenorientiert von Vaillant. Ich wurde mit meiner VR900 leider auch enttäuscht. Hatte die 2 Jahre im Schrank liegen, weil sie nicht wirklich stabil gelaufen ist und als ich letzte Woche mal schauen wollte, ob Vaillant inzwischen bei der Software nachgebessert hat, musste ich feststellen, dass die Box in die Tonne kloppen kann. Warum es nicht möglich sein soll, noch weiterhin ein Firmwareupdate anzubieten, ist mir schleierhaft (außer die Leute zu zwingen, eine neue Box kaufen zu müssen).
Falls jemand mit den VR 920 Gateways experimentieren will (das Ganze trifft vermutlich auch auf die VR 900 Gateways zu): Ein Login ins Linux-System über die serielle Konsole (siehe Bild, 3.3 Volt Pegel, 115200 Baud) ist nur als "root" mit Passwort möglich, das Passwort ist nicht bekannt. Wer versuchen will den Passwort-Hash zu knacken: die "/etc/shadow" Datei ist im Anhang. Das ist ein SHA-512 Hash und entsprechend rechenintensiv.
U-Boot kann normalerweise nicht unterbrochen werden (außer im Fall des Geräts des TO bei dem das Booten des Linux-Systems nicht funktioniert), daher kommt man normalerweise auch nicht auf die U-Boot Kommandozeile.
Allerdings ist JTAG für den i.MX6 verfügbar (siehe Bild, bitte beachten daß das Pinout auf dem Kopf steht), das ist das übliche 10-Pin ARM JTAG Pinout. JTAG auf dem i.MX6 ist nicht gesperrt, man kann daher relativ einfach U-Boot debuggen und z.B. einen Breakpoint setzen und dann die "bootdelay" Environment-Variable auf einen Wert größer 0 setzen. Von U-Boot kommt man dann z.B. durch Anhängen von "init=/bin/bash" an die Kernel Kommandozeile auch auf das Linux System.
IMG_1762.jpeg
(240 KB)
IMG_1761.jpeg
(240 KB)
