Seite 19 von 99
Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche 2019
Verfasst: 16.01.2020, 18:46
von hobbyquaker
jmaus hat geschrieben: ↑16.01.2020, 17:30
macht eine Änderung an einer Closed-Source Komponente (hss_led) der Firmware notwendig
An dem Punkt waren wir schon mal, aber ich komme nicht umhin das noch mal zu Erwähnen: Wesentlich besser aufgehoben als im hss_led wäre das Feature im (cr)rfd. Nur dann wäre dieses Feature auch für Nutzer von Apps, Zusatzsoftware und externer Software (die die UNREACH Meldung per RPC Event bekommen) sinnvoll nutzbar.
Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche 2019
Verfasst: 16.01.2020, 20:56
von MathiasZ
Ich schreibe dann später auf Github.
Ich habe es mit dem Handy versucht.
Ist die reinste Katastrophe
Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche 2019
Verfasst: 17.01.2020, 07:51
von MathiasZ
@tomi_cc16
die meisten Addons werden bereits mit der neuensten RM Firmware installiert, ohne dass die RaspberryMatic neu gestartet wird.
ich kenne z.Z. nur 2 Addons, die einen Neustart der RaspberryMatic durchführen. Auch muß man bei der RaspberryMatic die SD-Karte nicht mehr neu flashen. Das würde beim Tinkerboard S auch irgendwie keinen Sinn ergeben, weil da bekanntlich ein eMMc-Modul verbaut ist.
Die 2 einzigen Vorteile, die ich bei rm-update kenne, sind
1. es wird die Firmware für die richtige Hardware aufgespielt und man muß nicht
den Umweg über einen Download auf dem heimischen PC gehen.
2. die WLAN-Suche geht einfacher vonstatten.
Soviel ich aber mitbekommen habe, ist @jmaus dabei, das direkt in der Firmware zu implementieren.
Nun ein Edit meinerseits:
ich habe gerade ein Request erstellt, bzgl der Anzeige der Servicemeldungen am Funkmodul.
Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche 2019
Verfasst: 17.01.2020, 12:26
von klana
Hi,
Viele Wünsche habe ich nicht...
1. Das Systemlog soll bei der Einstellung "Fehler" auch nur diese enthalten und keine hunderte überflüssige Einträge, wie z.B.
"homematic-raspi daemon.debug rngd: Added 3365/4096 bits entropy"
2. eine moderne schnelle konfigurierbare WebUI
3. eine stabilere Kommunikation zu den Geräten
4. eine umfangreichere und weniger fehlerbehaftete Scriptsprache
Gruß
Klana
Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche 2019
Verfasst: 20.01.2020, 11:48
von jp112sdl
klana hat geschrieben: ↑17.01.2020, 12:26
Viele Wünsche habe ich nicht...
Kannst du das näher erläutern?
klana hat geschrieben: ↑17.01.2020, 12:26
eine moderne schnelle konfigurierbare WebUI
- modern, naja da gibts ja ein paar Ansätze (CSS Modding, NodeRed Dashboard)
- an welcher Stelle ist sie bei dir langsam?
klana hat geschrieben: ↑17.01.2020, 12:26
eine stabilere Kommunikation zu den Geräten
Zu welchen Geräten?
Was ist "stabiler"?
klana hat geschrieben: ↑17.01.2020, 12:26
umfangreichere und weniger fehlerbehaftete Scriptsprache
Welche Funktionen vermisst du?
Welche Fehler gibt es?
Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche 2019
Verfasst: 20.01.2020, 14:44
von klana
jp112sdl hat geschrieben: ↑20.01.2020, 11:48
klana hat geschrieben: ↑17.01.2020, 12:26
Viele Wünsche habe ich nicht...
Kannst du das näher erläutern?
Was denn? Das ich nur ein paar Wünsche habe???? Im Großen und Ganzen zufrieden bin?
klana hat geschrieben: ↑17.01.2020, 12:26
eine moderne schnelle konfigurierbare WebUI
- modern, naja da gibts ja ein paar Ansätze (CSS Modding, NodeRed Dashboard)
- an welcher Stelle ist sie bei dir langsam?
CCS Modding = händiges gefrickel....
NodeRed Dashboard = AddOn
Ich meine eine originale WebUI in schön und evtl. selbst per Klick oder Drag & Drop konfigurierbar.
klana hat geschrieben: ↑17.01.2020, 12:26
eine stabilere Kommunikation zu den Geräten
Zu welchen Geräten?
Was ist "stabiler"?
Zu allen Geräten! Wenn ich (nur ein Beispiel!) einen Fensterkontakt habe der noch nie in den letzten Jahren einen Kommunikationsfehler gemeldet hat, jetzt schon mehrfach einen meldet und dieser auch nicht alleine wieder weg geht, sondern erst wenn ich die Tür/das Fenster einmal öffnen muss.
Das finden ich nicht gut. Wie gesagt das ist nur ein!! Beispiel von vielen.
ApproPo Kommunikation: es sollte doch möglich sein bei einer Installation (Anlernen oder Firmwareupdate) die DutyCycle Limitation auszuschalten.
Während des normalen Betriebs ist das ja OK, aber wenn mal ein Firmwareupdate kommt, dann dauert alles ewig.
klana hat geschrieben: ↑17.01.2020, 12:26
umfangreichere und weniger fehlerbehaftete Scriptsprache
Welche Funktionen vermisst du?
Welche Fehler gibt es?
Welche Fehler es gibt und wie verkrüppelt die Scriptsprache ist, das weiß wohl jeder....soll ich jetzt alles hier aufzählen?
Gruß
Klana
Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche 2019
Verfasst: 20.01.2020, 14:53
von jp112sdl
klana hat geschrieben: ↑20.01.2020, 14:44
Wenn ich (nur ein Beispiel!) einen Fensterkontakt habe der noch nie in den letzten Jahren einen Kommunikationsfehler gemeldet hat, jetzt schon mehrfach einen meldet und dieser auch nicht alleine wieder weg geht, sondern erst wenn ich die Tür/das Fenster einmal öffnen muss.
Das finden ich nicht gut.
Evlt. sind nur die zyklischen Mitteilungen deaktiviert?
Vielleicht reicht es auch, das Paramset noch mal zu übertragen?
Oder das Gerät komplett ablernen + Reset?
Explizit mit RaspberryMatic wird das nichts zu tun haben.
klana hat geschrieben: ↑20.01.2020, 14:44
Welche Fehler es gibt und wie verkrüppelt die Scriptsprache ist, das weiß wohl jeder....soll ich jetzt alles hier aufzählen?
Tut mir leid, bei meinen Skripten stoße ich weder auf Limitationen noch auf Fehler.
klana hat geschrieben: ↑20.01.2020, 14:44
Es sollte doch möglich sein bei einer Installation (Anlernen oder Firmwareupdate) die DutyCycle Limitation auszuschalten.
Du weißt schon, dass diese Limitation eine
gesetzliche Vorgabe ist?
Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche 2019
Verfasst: 20.01.2020, 15:10
von jmaus
klana hat geschrieben: ↑20.01.2020, 14:44
ApproPo Kommunikation: es sollte doch möglich sein bei einer Installation (Anlernen oder Firmwareupdate) die DutyCycle Limitation auszuschalten.
Während des normalen Betriebs ist das ja OK, aber wenn mal ein Firmwareupdate kommt, dann dauert alles ewig.
Du weisst schon das es sich bei dem DutyCycle um eine gesetzliche Vorgabe handelt und das sich eQ3 strafbar machen würde wenn es (auch nur zeitweise) erlauben würde die DutyCycle Begrenzung zu deaktivieren bzw. abzuändern...
Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche 2019
Verfasst: 20.01.2020, 15:21
von Xel66
Es ist ja auch nicht so, dass die Informationen zum genutzten Sendefrequenzband, dessen nicht exklusive Nutzung und die gesetzlichen Regeln und Beschränkungen in jeder mitgelieferten Anleitung eines Funkaktors oder -sensors explizit aufgeführt ist. Und nicht nur der Hersteller würde sich strafbar machen sondern auch der Betreiber einer in dem Falle ungenehmigten Sendeanlage. Es ist zwar relativ unwahrscheinlich, dass einem Anwender da was passiert, aber ich würde darauf keine Wette platzieren. Es reicht ein anderer Anwender aus, der seinen Kommunikationsstörungen intensiver nachgeht und offizielle Nachforschungen bezüglich eines erkannten Dauersignals einleitet. Läge z.B. meine Installation permanent auf dem Bauch, weil jemand anderes eine manipulierte Anlage betreibt, würde ich das auch zum Einmessen melden. Mit dieser 1%-Regelung soll die Koexistenz der Systeme gewährleistet werden.
Gruß Xel66
Re: RaspberryMatic - Verbesserungsvorschläge/Wünsche
Verfasst: 20.01.2020, 16:33
von Roland M.
Hallo!
Da der Thread ursprünglich "2018" im Betreff führte, was dann einmal auf "2019" geändert wurde, wir aber mittlerweile 2020 schreiben, habe ich die Jahreszahl ganz einfach aus dem Betreff entfernt.
Die Wünsche bleiben ja die gleichen...
Roland