jens-maus / RaspberryMatic

:house: A feature-rich but lightweight, buildroot-based Linux operating system alternative for your CloudFree CCU3/ELV-Charly 'homematicIP CCU' IoT smarthome central. Running as a pure virtual appliance (ProxmoxVE, Home Assistant, LXC, Docker/OCI, Kubernetes/K8s, etc.) on a dedicated embedded device (RaspberryPi, etc.) or generic x86/ARM hardware.
https://raspberrymatic.de
Apache License 2.0
1.54k stars 190 forks source link

Nightly Snapshot 3.53.27.20200901-cd0aee #898

Closed Bono1969 closed 4 years ago

Bono1969 commented 4 years ago

Describe the bug A clear and concise description of what the bug is.

Habe soeben das aktuellste Snapshot installiert. Beim ersten Neustart wurde die Firmware des HM-MOD-RPI-PCB von 4.0.xx auf 4.2.6 upgedatet. Nach erfolgreichem Start habe ich das System über die Oberfläche nochmal heruntergefahren, spannungslos gemacht und neu gestartet. Beim jetzigen Hochfahren wird folgendes gezeigt. 3F3DBD3F-1A6C-4CDA-84BC-229B152D46D9

Noch schlimmer ist folgendes. Auch die Konfiguration ist verschossen. 34F7C085-412A-462B-B695-C11732365C0D

To Reproduce Steps to reproduce the behavior:

  1. Go to '...'
  2. Click on '....'
  3. Scroll down to '....'
  4. See error

Expected behavior A clear and concise description of what you expected to happen.

Screenshots If applicable, add screenshots to help explain your problem.

System information (please complete the following information):

Additional context Add any other context about the problem here.

jens-maus commented 4 years ago

Danke für die Infos. Dann hoffe ich du hast ein Backup gemacht bevor du auf diesen unstable snapshot geupdatet hast.

Und ist das wirklich ein HM-MOD-RPI-PCB was da auf dem HB-RF-USB sitzt? Wenn ja würde mich interessieren als was der aktuellen snapshot es erkannt hat? Vmtl als RPI-RF-MOD und hat deshalb fälschlicherweise es auf die 4.x firmware geflasht? Sollte eigentlich nicht möglich sein. Oder ist das doch ein RPI-RF-MOD was da auf dem HB-RF-USB sitzt und das wird jetzt mit aktueller 4.2.x firmware fälschlicherweise als HM-MOD-RPI-PCB erkannt von dem älteren RM?!? Das wäre natürlich auch ungünstig.

Bono1969 commented 4 years ago

Hallo Jens, es ist das große Modul. Hilft downgraden oder nur Restore?

Bono1969 commented 4 years ago

Downgraden und Restore haben nichts gebracht. Das Modul wird immer noch als falsches behandelt.

jens-maus commented 4 years ago

@Bono1969 Es scheint wohl an der neuen Funkmodul Firmware 4.2.x des RPI-RF-MOD zu liegen das dieses nicht mehr als RPI-RF-MOD mit einem HB-RF-USB zusammen erkannt wird. Vielleicht hat @alexreinert ja eine Idee woran das liegen könnte bevor ich mich auf die Suche mache. Für ein Downgrade auf frühere Versionen kann das aber in der Tat kritisch sein weil es ja dann als das kleine HM-MOD-RPI-PCB erkannt wird. Die Frage wäre nur geht aber ggf. doch trotzdem alles auch wenn unter einer alten 3.51.6.XXXXX version mit der neuesten 4.2.x RPI-RF-MOD Firmware hantiert wird?

alexreinert commented 4 years ago

Ich habe tatsächlich eine Idee: Bis Firmware 4.0.20 wurde beim RPI-RF-MOD bei Verwendung vom eq3configcmd die Radio MAC 0x??ffff geliefert. Bei Firmware 4.2.6 wird da jetzt fix 0x000000 geliefert.

jens-maus commented 4 years ago

@alexreinert Danke für den Hinweis, Alex. Das würde das in der Tat erklären. Bringt dann zwar nix für die alten Versionen, aber in kommenden kann ich das dann entsprechend einbauen. Schaue ich mir heute Abend an. Danke.

Bono1969 commented 4 years ago

Enthält die 902er Build schon einen fix?

jens-maus commented 4 years ago

@Bono1969 Nein, sonst hättest du das hier im Ticket ja schon gesehen weil ich dann den commit damit verlinkt hätte. Solange das also nicht der Fall ist wird auch kein nightly snapshot da einen Fix haben. Und wann ich dazu komme muss ich erst noch sehen.

Bono1969 commented 4 years ago

Alles klar, Danke für die Info. Nicht böse sein ich bin ungeduldig🤓 Deshalb installiere ich aus Prinzip immer täglich alle Updates und auch die Snapshots. Ist das erste mal das was schief gelaufen ist. Aber nur so kommt man auf Fehler drauf👍🏻

jens-maus commented 4 years ago

Ok, allerdings solltest du davon abstand nehmen diese snapshots in deinem produktiven System einzusetzen. Dir sollte ja bekannt sein das damit von einfachem Nicht-Booten bis Datenverlust alles passieren kann. Und so kann es eben sein das du jetzt ein paar Tage warten musst bis ich dazu gekommen bin daran zu arbeiten.

Bono1969 commented 4 years ago

Danke Jens, kein Problem. Deshalb geht bei mir nicht die Welt unter😃

alexreinert commented 4 years ago

Im Commit https://github.com/alexreinert/piVCCU/commit/35cc0a4c1a0cf407de90ce529ce2de3e62510c62 von piVCCU habe ich die Anpassung gemacht, dass müsstest du analog übernehmen können.

jens-maus commented 4 years ago

Danke @alexreinert für diesen hilfreichen Hinweis. Werde ich wohl gleich einfach mal blind einarbeiten weil mir gerade die Zeit zum testen fehlt, aber dann kann @Bono1969 ja reporten ob es das Problem ggf. löst und das RPI-RF-MOD mit den kommenden 3.53.27.XX versionen mit nutzung eines HB-RF-USB richtig erkennt.

Allerdings bleibt dann natürlich weiterhin das problem das bei einem downgrade auf eine frühere Version er das RPI-RF-MOD mit 4.2.6 firmware immer noch als HM-MOD-RPI-PCB erkennt. Ob das allerdings in irgendeiner weise dann negative Effekte auf die Funktion hat wenn unter 3.51.6 man mit einer 4.2.6 Funkmodulfirmware hantiert kann ich aktuell schwer abschätzen.

alexreinert commented 4 years ago

Ja, das Problem mit dem Downgrade macht mir auch etwas Kopfschmerzen bei piVCCU und debmatic. Ich konnte Probleme mit der 4.2.6 unter 3.51.6 feststellen, mir war es nicht mehr möglich, ein HmIP Gerät anzulernen. Allerdings habe ich noch nicht die Zeit für einen qualifizierten Test des Problems gefunden, es könnte auch sein, dass das von mir verwendete HmIP Gerät einen Schuss hat.

jens-maus commented 4 years ago

Alles klar, dann wird es wohl wirklich Zeit für ein separates Tool das wirklich identifizieren kann ob es sich um ein RPI-RF-MOD oder HM-MOD-RPI-PCB handelt statt immer zu versuchen hier via reverse-engineering rauszubekommen wie man die Unterscheidung machen kann. Hast du dafür schon einen Ansatz gefunden? Eigentlich wollte eQ3 hier immer mal etwas ausarbeiten/liefern, aber bis jetzt ist da trotz nachfragen noch nichts passiert.

Und wie verhält sich das eigentlich ohne HB-RF-USB? Passiert da das gleiche? Ich kam da leider wirklich noch nicht zum testen.

alexreinert commented 4 years ago

Das Problem liegt an der Firmware vom Funkmodul und ist unabhängig davon, über welche Hardware es angeschlossen ist. Bei dir kommt es beim GPIO Header nur deswegen nicht zum tragen, weil du da ja aufgrund der Existenz der Epson RTC entscheidest.

An dem Erkennungstool bin ich dran. Die eigentliche State Machine habe ich in der Firmware der HB-RF-ETH ja jetzt implementiert, ich muss das jetzt nur noch in ein Konsolenprogramm gießen.

jens-maus commented 4 years ago

Alles klar, das wäre wirklich mal wieder eine super Sache von dir wenn es solch ein Tool geben würde , auch wenn du dieses Tool dann ggf. als open source veröffentlichen könntest. Gib bescheid wenn du irgendwie Hilfe dabei benötigst und sei es nur das eben in ein Konsolenprogramm zu gießen.

Bono1969 commented 4 years ago

Hallo die Herren, selbstverständlich werde ich das ausprobieren. Wenn Ihr spezielle Informationen benötigt dann muss ich wissen wie die Befehle lauten, welche Logfiles benötigt werden.... Bis dahin danke für Eure Bemühungen.