Neue Release-Candidate/Testversion (3.53.30.20201020) verfügbar

Einrichtung, Nutzung und Hilfe zu RaspberryMatic (OCCU auf Raspberry Pi)

Moderatoren: jmaus, Co-Administratoren

Benutzeravatar
jmaus
Beiträge: 9862
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 464 Mal
Danksagung erhalten: 1880 Mal
Kontaktdaten:

Neue Release-Candidate/Testversion (3.53.30.20201020) verfügbar

Beitrag von jmaus » 20.10.2020, 08:52

Hallo Zusammen,

nach einem Monat Entwicklungszeit steht für kommendes Wochenende mal wieder einen neuen Release von RasberryMatic an. Meine eigenen Tests der darin umgesetzten Änderungen sind zwar alle bisher problemlos verlaufen, trotzdem möchte ich hier nun darum bitten doch – wenn möglich – eigene Tests durchzuführen damit der kommende Release mit keinen unerwartenden Überraschungen aufwartet. Es gibt zwar schon seit längerem tägliche nightly builds von RaspberryMatic bei dem jede Nacht automatisch (wenn es Änderungen gibt) eine neue Testversion generiert wird die jeder Interessierte entsprechend testen kann.

Die jeweils aktuellste Test/Release-Candidate Version kann unter folgender URL für die jeweilige Plattform heruntergeladen werden:

https://github.com/jens-maus/RaspberryM ... /snapshots

Der aktuelle Release-Candidate trägt die Versionsnummer 3.53.30.20201020 und wird zum momentan geplanten Releasetermin (vmtl. zum Samstag/Sonntag) noch einmal umbenannt/angepasst/verändert werden. Trotzdem kann jeder interessierte Tester gerne diese einmal auf seine CCU Umgebung loslassen und sollte bitte entsprechendes Feedback zum aktuellen Stand hier geben.

WARNUNG:
Bitte hierbei beachten, das diese Version natürlich nur Personen testen sollten die wissen was sie tun bzw. auf was sie sich hier einlassen. Das beinhaltet mögliche geringfügige Probleme bis hin zu eventuellem möglichem Verlust der gesamten Konfiguration. Deshalb heisst es hier nicht nur: vorher ein entsprechendes Backup zu machen, sondern eben auf etwaige unvorhersehbare Dinge vorbereitet zu sein! Und daher wäre es natürlich am besten diese Tests auf separater Testhardware durchzuführen.
Natürlich sollte meiner momentanen Einschätzung nach es keine größeren Probleme mit dieser Version geben, aber ich möchte hier trotzdem vor davor warnen, da ich diese Versionen selber noch nicht ausreichend getestet habe.

Wer aber trotz dieser Warnungen gerne aktiv mithelfen will die kommende Version vorher zu testen um etwaige Last-Minute-Probleme besser ausschliessen zu können, sei herzlich eingeladen dies zu tun und mir dann bitte entsprechend im GitHub bzw. hier im Forum etwaig aufkommende Probleme (oder aber auch nur ein "Alles ok mit der rpi4 version") zu melden.

Die in dieser Version eingearbeiteten Änderungen sind wie folgt (nur momentan in unformatiertem Englisch verfügbar):

Code: Alles auswählen

#### CCU/HomeMatic service changes:
- integrated update of [OCCU](https://github.com/eq-3/occu) firmware to [3.53.30-2](https://github.com/jens-maus/occu/tree/b_3_53) version with full compatibility to the [CCU3 3.53.30 firmware](https://www.eq-3.de/downloads/software/firmware/ccu3-firmware/CCU3-Changelog.3.53.30.pdf) which comes with the following changes:
  - updated `ReGaHss` logic engine `R1.00.0388.0224 (Sep 29 2020)` version with the following changes:
    - fixed a zero-day issue in the internal script parser which didn't work correctly with nested method calls if the outer and inner method  were allowed to take 2+ parameter. This created invalid runtime errors while the execution of these nested calls should have been perfectly valid (#922).
- largely reworked/simplified the RF module initialisation/setup so that the new `detect_radio_module` tool kindly developed by @alexreinert is used while keeping the basic functionality to combine multiple RF modules for a shared DutyCycle use. In addition, the device type (`HB-RF-USB`, `GPIO`, etc.) will be put into a new variable in `/var/hm_mode`. Furthermore we now can correctly query a `HM-MOD-RPI-PCB` connected to a `HB-RF-USB` or `HB-RF-USB-2` (#910, #911).
- slightly increased the timeout for the RF module firmware update process so that a firmware update of the old HM-MOD-RPI-PCB is guaranteed to proceed in time.
- fixed `/etc/init.d/S06InitSystem` to make sure a missing `/usr/local/sdcard/measurement` directory exists so that the cronjob and HMIPServer init script can copy the content of the `/tmp/measurement` to the permanent storage (#913).
- integrated a new OCCU bugfix patch which will fix the BidCos-RF description file of the `HM-OUT-CFM-TW` device by using `0xA4` instead of `0x24` for the index of `LONG_ACT_TYPE` (#915, @jp112sdl).
- integrated a fix for the Mediola NEO CCU Addon so that it will not be included in the standard system configuration backup since the Addon doesn't really contain any user configuration, thus can be omitted from being part of the backup.
- added `/usr/local/eQ-3-Backup` to the standard paths being omitted from the system config backup. This should fix issues where upon switching from a CCU3 firmware to RaspberryMatic resulted in this path being part of the config backup.

#### WebUI changes:
- added new 0080-WebUI-Fix-SideIncOpenTag WebUI patch to fix an invalid placed open tag `<` character in an emitted html statement in `side.inc` (@jp112sdl).
- added new 0081-WebUI-Fix-DecalcificationTimeMinute00 WebUI patch fixing the selection of 00 minutes in the decalcification UI (#931, @jp112sdl).
- added new 0082-WebUI-Fix-SetVisibilityScriptError WebUI patch fixing `ScriptRuntimeError` outputs resulting from trying to change the visibility of based on the channel id (#919, @jp112sdl).
- added new 0083-WebUI-Fix-DeviceTestScriptError WebUI patch fixing `ScriptRuntimeError` outputs resulting from trying to apply a test on a device rather than on a single channel (#939, @jp112sdl).
- slight improvement of 0038-WebUI-DeviceOverview-StatusColumn WebUI patch to check for a non existing rssiListHmRF variable as otherwise a js exception is raised in the WebUI.
- added a new 0084-WebUI-Fix-InvalidObjectCrashes WebUI bugfix patch which should workaround/fix issues where the room view could not be displayed anymore if an added channel hasn't any valid linked device anymore (#944).

#### Operating system changes:
- added the missing E1000E package to get the network interface working again in the recovery system for the ova/intelnuc platform.
- added more kernel config options to streamline all NUC hardware support somewhat more.
- added buildroot patch to update ethtool to version 5.8 to fix the `netlink error: No such file or directory` error which appeared with 5.7 (cf. https://www.spinics.net/lists/netdev/msg659759.html).
- added HyperV-PCI kernel config options to optimize use of the OVA variants in HyperV setups.
- enabled drivers for Intel Network devices with Virtual Function for OVA platform.
- added a commented out `dtparam=sd_poll_once=on` entry in `/boot/config.txt` to let users know how to poll only once for a missing sd card in case USB drive boot is used with a RaspberryPi.
- integrated a minor fix for the `/bin/updateTZ.sh` script which should catch rare cases where an empty `/etc/config/TZ` file could have caused a situation of an invalid `/etc/config/localtime` symlinking. In addition, `updateTZ.sh` will now only update files in `/etc/config` in case something was actually changed. This should omit write operations upon startup. (cf. https://homematic-forum.de/forum/viewtopic.php?f=65&t=61426).
- added support for Intel NUC6CAYH model which stalled upon bootup due to issues with the i915 DRM driver. Now we completely omit the DRM driver and just rely on stupid framebuffer devices for a HDMI debug output. In addition, more IWLWIFI firmwares were added so that also the wifi of the NUC6CAYH should be supported now (#930).
- fixed an issue with OS time synchronisation which didn't work correctly anymore as soon as a network link up/down event was identified during runtime. This caused the RTC time to be read out regularly instead which also was incorrectly written back by the NTP because it was written in local time rather than in UTC time.
- slightly reworked the `eQ3StartNetwork` and `eQ3StopNetwork` ifup/ifdown scripts to deal better with static IP address setups which could explain certain issues people were having with not having a link available during bootup (#471).
- modified the standard `.ovf` template file to use `ovf:id=99` in `OperatingSystemSection` so that a 2.x/3.x/4.x Linux system is assumed and thus VMXNET3 can be manually selected as a network interface in vmWare ESXi (https://homematic-forum.de/forum/viewtopic.php?f=65&t=61792)
- fixed issue where upon an unclean shutdown the corresponding status file was not correctly cleared and thus the log file was continued to be filled with unclean shutdown events (#955).
- integrated a fix for `S01InitHost` in the recovery system where could happen that at the time the `lsblk` command is executed the partuuid could not be extracted yet, thus we retrieve the mmcX string using the mountpoint only.
- updated U-Boot bootloader for all supported target platforms (RaspberryPi, Tinkerboard) to latest 2020.10 version.
- updated buildroot/Linux environment to latest 2020.08.1 version.
- updated Linux kernel versions to new major LTS 5.4.x version (5.4.70) for all supported platforms.
- updated Raspberry Pi kernel+firmware to latest 1.20200902 version
Ich würde wie gesagt gerne darum bitten diese Version ausführlichen Tests zu unterziehen und auf Herz- und Nieren zu prüfen damit ich dann bis zum finalen Releasetermin noch genug Zeit habe ggf. noch Modifikationen vorzunehmen falls irgendetwas nicht so gehen sollte wie erwartet.

Aber auch sonst freue ich mich wie immer über entsprechendes, auch generelles Feedback. Und bitte bei Feedback immer explizit dazu schreiben welche Hardwareplatform bzw. Imagedatei verwendet wurde damit ich entsprechendes hier vermerken kann.

Viel Spaß beim Testen!
RaspberryMatic 3.75.7.20240420 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ☕️

Raspihausfan_1
Beiträge: 393
Registriert: 26.06.2018, 11:02
Hat sich bedankt: 4 Mal
Danksagung erhalten: 11 Mal

Re: Neue Release-Candidate/Testversion (3.53.30.20201020) verfügbar

Beitrag von Raspihausfan_1 » 20.10.2020, 09:02

So, ich bin am installieren (Tinkerboard S). Die letzte offizielle FW brachte täglich eine Alarmmeldung, weil die Fritzbox längere Synchronisationsfehler hatte (bis zu einer Stunde). Mal sehen, wie jetzt das Verhalten dieser Testvesion ist.
Testversion (3.53.30.20201020)

Benutzeravatar
jmaus
Beiträge: 9862
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 464 Mal
Danksagung erhalten: 1880 Mal
Kontaktdaten:

Re: Neue Release-Candidate/Testversion (3.53.30.20201020) verfügbar

Beitrag von jmaus » 20.10.2020, 09:28

Raspihausfan_1 hat geschrieben:
20.10.2020, 09:02
So, ich bin am installieren (Tinkerboard S). Die letzte offizielle FW brachte täglich eine Alarmmeldung, weil die Fritzbox längere Synchronisationsfehler hatte (bis zu einer Stunde).
Und was war das inhaltlich für eine Alarmmeldung? Fehlendes Internet oder NTP Zeit Offset?
RaspberryMatic 3.75.7.20240420 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ☕️

Raspihausfan_1
Beiträge: 393
Registriert: 26.06.2018, 11:02
Hat sich bedankt: 4 Mal
Danksagung erhalten: 11 Mal

Re: Neue Release-Candidate/Testversion (3.53.30.20201020) verfügbar

Beitrag von Raspihausfan_1 » 20.10.2020, 10:23

Hier ist die Alarmmeldung von heute (3.53.30.20200919):
2020-10-20_Watchdogalarm.JPG
Internetausfall auf Fritzbox (Ereignisausschrift)
2020-10-20_Synchronisationsfehelr.JPG
Und hier die Synchronisation
2020-10-20_Fritzbox DSL Statistik.JPG
Die Fritzbox ist hier nicht das Thema (nur zur Info: FB 7590 neu).
Was mir nicht so gefällt, ist die Alarmmeldung. Konkret: Internetausfall.
Dieses Posting könnte auch in die letzte offizielle FW verschoben werden, aber interessant ist, ob das Verhalten auch in dieser Testversion zu beobachten ist.
Bis jetzt läuft die Testversion einwandfrei.

Benutzeravatar
jmaus
Beiträge: 9862
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 464 Mal
Danksagung erhalten: 1880 Mal
Kontaktdaten:

Re: Neue Release-Candidate/Testversion (3.53.30.20201020) verfügbar

Beitrag von jmaus » 20.10.2020, 10:52

Raspihausfan_1 hat geschrieben:
20.10.2020, 10:23
Was mir nicht so gefällt, ist die Alarmmeldung. Konkret: Internetausfall.
Dieses Posting könnte auch in die letzte offizielle FW verschoben werden, aber interessant ist, ob das Verhalten auch in dieser Testversion zu beobachten ist.
Bis jetzt läuft die Testversion einwandfrei.
Und inwiefern sollte dieses "Verhalten" in der Testversion anders sein? RaspberryMatic hat doch recht, das dein Internet zweimal ausgefallen ist und darüber informiert es dich eben. Wenn dich das nicht interessiert dann musst du das eben entweder ignorieren oder die Meldung via folgendem Befehl bzw. anlegen dieser Datei "/etc/config/internetCheckDisabled" ausschalten:

Code: Alles auswählen

touch /etc/config/internetCheckDisabled
RaspberryMatic 3.75.7.20240420 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ☕️

1techone
Beiträge: 213
Registriert: 19.01.2016, 10:23
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 49 Mal
Danksagung erhalten: 19 Mal

Re: Neue Release-Candidate/Testversion (3.53.30.20201020) verfügbar

Beitrag von 1techone » 20.10.2020, 12:14

Hallo,
habe per Systemsteuerung/Zentralenverwaltung meinen Raspi 3+ mit kleinem (alten) Funkmodul auf diese Testversion "geupdatet".
Alles läuft bei mir bestens : HM , HMIP sowie "Jerome-Nachbauten"
-alle Programme, auch Zeitgesteuerte, laufen anstandslos !
(3.53.30.20200919 lief bei mir auch ohne Fehler)
Danke für die tolle Arbeit.
Gruß Jürgen

Benutzeravatar
Baxxy
Beiträge: 10832
Registriert: 18.12.2018, 15:45
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 608 Mal
Danksagung erhalten: 2227 Mal

Re: Neue Release-Candidate/Testversion (3.53.30.20201020) verfügbar

Beitrag von Baxxy » 20.10.2020, 12:50

Raspihausfan_1 hat geschrieben:
20.10.2020, 10:23
Was mir nicht so gefällt, ist die Alarmmeldung. Konkret: Internetausfall.
Was gefällt dir denn daran nicht? Da der Alarm erst ausgelöst wird wenn das Internet länger als 5min weg ist bekommt man doch bei der üblichen "Zwangstrennung" davon gar nichts mit. Bei längerem Ausfall wird dann eben der Alarm getriggert. Oder auch nicht wenn man es, wie jmaus beschrieben hat, deaktiviert hat.

Raspihausfan_1
Beiträge: 393
Registriert: 26.06.2018, 11:02
Hat sich bedankt: 4 Mal
Danksagung erhalten: 11 Mal

Re: Neue Release-Candidate/Testversion (3.53.30.20201020) verfügbar

Beitrag von Raspihausfan_1 » 21.10.2020, 09:09

Auch eine Zwangstrennung hat bei mir schon mehr als 5 Minuten gedauert. Wenn das Internet z. B. nach 30 Min. wieder da ist, dann ist es für mich keine Alarmmeldung, welcher ich nachgehen muss. Das könnte noch eine Serviceinformation sein, bzw. Eingang im Log finden.

Ich bringe mal ein Zitat aus der Wikipedia:
"Ein Alarm ist ein akustisches oder optisches Notsignal. In einem allgemeineren Sinne wird als Alarm jedwede Warnung bezeichnet, die auf eine drohende Gefahr aufmerksam macht und zu erhöhter Wachsamkeit aufruft, oder auch der Zustand akuter Gefährdung und erhöhter Bereitschaft („einen Alarm verhängen/aufheben“)."

Und in diesem Sinne ist der temporäre Ausfall des Internets nicht zu verstehen. Die Haussteuerung ist für die interne Kommunikation und Funktion der verbauten Komponnenten zuständig.
Mir reicht es, wenn Jens mir verrät, an welcher Stelle ich die Zeitspanne bis zur Alarmmeldung vergrößern kann.
Diese Nacht gab es wieder einen Synchronisationsaufall, aber nur 2 Minuten lang. Da hat RM natürlich nichts gemeldet, was OK ist.
Interessantes Detail am Rande: zu Testzwecken lasse ich parallel noch eine PiVCCU3 auf einem RasPi 4 ohne reale Geräte mitlaufen. Das treten diese Alarmmeldungen nicht auf.

Benutzeravatar
jmaus
Beiträge: 9862
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 464 Mal
Danksagung erhalten: 1880 Mal
Kontaktdaten:

Re: Neue Release-Candidate/Testversion (3.53.30.20201020) verfügbar

Beitrag von jmaus » 21.10.2020, 09:12

Raspihausfan_1 hat geschrieben:
21.10.2020, 09:09
[...]
Mir reicht es, wenn Jens mir verrät, an welcher Stelle ich die Zeitspanne bis zur Alarmmeldung vergrößern kann.
Ich hab dir doch schon verraten wie man die Alarmmeldung bzw. die Internetprüfung gänzlich ausschaltet. Das muss genügen wenn dich das stört. Dann schalt sie eben einfach aus und gut ist.
Raspihausfan_1 hat geschrieben:
21.10.2020, 09:09
Interessantes Detail am Rande: zu Testzwecken lasse ich parallel noch eine PiVCCU3 auf einem RasPi 4 ohne reale Geräte mitlaufen. Das treten diese Alarmmeldungen nicht auf.
Na das ist nicht verwunderlich, denn diese WatchDog Alarmmeldungen (inkl. der Internetprüfung/alarmmeldung) sind ein alleiniges Feature von RaspberryMatic und das gibt es weder in einer CCU3 Firmware noch in piVCCU oder debmatic.
RaspberryMatic 3.75.7.20240420 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ☕️

Georgee
Beiträge: 156
Registriert: 22.05.2017, 11:58
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 5 Mal
Danksagung erhalten: 4 Mal

Re: Neue Release-Candidate/Testversion (3.53.30.20201020) verfügbar

Beitrag von Georgee » 21.10.2020, 12:23

Hallo,

diese Version 1020 läuft seit fast 20 Stunden ohne jede Auffälligkeit.

Update über WebUI, keine Zeitdifferenzen gefunden.

Alles ganz prima, vielen Dank, Jens.

Georgee
Tinker Board S, aktuelle Version, kleines Funkmodul mit USB-2, USV, ca. 45 Geräte, CUxD, Mail, Programme drucken, ccu-historian mit Highcharts, hm-pdetect

Gesperrt

Zurück zu „RaspberryMatic“