Architektur rfd, hs485d, crRFD usw

Fragen, Support etc.

Moderator: Co-Administratoren

theshmike
Beiträge: 28
Registriert: 12.01.2018, 11:54

Re: Architektur rfd, hs485d, crRFD usw

Beitrag von theshmike » 27.11.2020, 11:31

jp112sdl hat geschrieben:
27.11.2020, 11:24
Dann nimm doch eine bestehende Appliance (CCU3 FW, Raspberrymatic, debmatic, ...) und schmeiß die von dir nicht benötigten Dienste (sofern sie denn stören, wenn sie einfach nur mitlaufen) aus dem init.d raus.
So hast du auch immer einen konsistenten Stand mit der vom HMIPServer benötigten Java-Version.
Stimme Dir prinzipiell zu, wäre die einfachste Variante. Das Einzige was mir im Weg steht ist der Ehrgeiz, die Dinge zu durchdringen und zu verstehen :mrgreen:
Und eigentlich wäre ich auch ganz gerne unabhängig von anderen Projekten indem ich halt verstehe, wie der Spaß funktioniert.

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

Re: Architektur rfd, hs485d, crRFD usw

Beitrag von jmaus » 27.11.2020, 12:09

theshmike hat geschrieben:
27.11.2020, 11:31
jp112sdl hat geschrieben:
27.11.2020, 11:24
Dann nimm doch eine bestehende Appliance (CCU3 FW, Raspberrymatic, debmatic, ...) und schmeiß die von dir nicht benötigten Dienste (sofern sie denn stören, wenn sie einfach nur mitlaufen) aus dem init.d raus.
So hast du auch immer einen konsistenten Stand mit der vom HMIPServer benötigten Java-Version.
Stimme Dir prinzipiell zu, wäre die einfachste Variante. Das Einzige was mir im Weg steht ist der Ehrgeiz, die Dinge zu durchdringen und zu verstehen :mrgreen:
Und eigentlich wäre ich auch ganz gerne unabhängig von anderen Projekten indem ich halt verstehe, wie der Spaß funktioniert.
Das steht IMHO aber nicht im Gegensatz dazu doch auf bestehenden OpenSource Projekten aufzubauen und jetzt nicht anfangen zu wollen sein komplett eigenes Süppchen zu kochen. Es sollte dir doch komplett möglich sein auch mit Blick auf Internas der Projekte die es bereits gibt (piVCCU, debmatic, RaspberryMatic) das genauer zu analysieren. Und vielleicht kommt dabei ja dann sogar etwas heraus (Neue features, bugfix requests, etc.) was du den Projekten zurück liefern kannst und dich damit gemeinschaftlich daran beiteiligen und ggf. so auch bedanken kannst, statt alles nur in deinem Kämmerchen und nur für dich zu tun...
RaspberryMatic 3.53.34.20201121 @ ESXi, ~190 Hm-RF/HmIP-RF/HmIPW Geräte, ioBroker – RaspberryMatic GitHub Projekt / Twitter

theshmike
Beiträge: 28
Registriert: 12.01.2018, 11:54

Re: Architektur rfd, hs485d, crRFD usw

Beitrag von theshmike » 27.11.2020, 12:16

jmaus hat geschrieben:
27.11.2020, 12:09

Das steht IMHO aber nicht im Gegensatz dazu doch auf bestehenden OpenSource Projekten aufzubauen und jetzt nicht anfangen zu wollen sein komplett eigenes Süppchen zu kochen. Es sollte dir doch komplett möglich sein auch mit Blick auf Internas der Projekte die es bereits gibt (piVCCU, debmatic, RaspberryMatic) das genauer zu analysieren. Und vielleicht kommt dabei ja dann sogar etwas heraus (Neue features, bugfix requests, etc.) was du den Projekten zurück liefern kannst und dich damit gemeinschaftlich daran beiteiligen und ggf. so auch bedanken kannst, statt alles nur in deinem Kämmerchen und nur für dich zu tun...
Stimme Dir voll und ganz zu, das eine schließt das andere ja auch gar nicht aus!

Jk2020
Beiträge: 36
Registriert: 22.06.2014, 11:20

Re: Architektur rfd, hs485d, crRFD usw

Beitrag von Jk2020 » 10.01.2021, 11:00

theshmike hat geschrieben:
27.11.2020, 12:16
jmaus hat geschrieben:
27.11.2020, 12:09

Es sollte dir doch komplett möglich sein auch mit Blick auf Internas der Projekte die es bereits gibt (piVCCU, debmatic, RaspberryMatic) das genauer zu analysieren.
Stimme Dir voll und ganz zu, das eine schließt das andere ja auch gar nicht aus!
würde dir Raspian mit piVCCU(3) auf rpi4 empfehlen, einfach zu installieren und läuft stabil. Ich hab das in Kombination mit openhab, nodered, mqtt etc kombiniert und läuft super stabil. Einziger Nachteil: Das Funkmodul passt nicht direkt auf die gpio-ports weil die physikalischen Abmessungen des Funkmoduls mit dem LAN-Port kollidieren.

Antworten

Zurück zu „Allgemeines zur OCCU“