Edomi

[BadSmiley]

Ne. Du brauchst da schon was dickeres und mindestens 8gb RAM. Ansonsten hier http://www.synology-forum.de/showthr...Box-auf-der-DS

[coliflower]

OT an

OK, danke, werde mal die 117 Seite bei Gelegenheit lesen (müssen), da ich eine zweite NAS als Backup bekommen soll, wir die Neue sicher ausreichen ;-)
Ansonsten am MacMini in der VM oder ...

OT aus

[tuxedo]

Meine Überlegung (zunächst) ist eher in Richtung VM, d.h. ich erstelle eine komplette VM einschl. Betriebssystem, die dann problemlos verteilt werden kann. Hier muss ich mich allerdings noch schlau machen, wie die VM entsprechend geschützt werden kann, damit man den Quelltext nicht "rausziehen" kann. Da wird es sicher Möglichkeiten geben.

Wie gut das "verschleiern" selbst in einem "abgeschlossenen Betriebssystem" funktioniert, sieht man am Beispiel HS.

Nur wer weiß schon, in welchen Foren und Märkten mein geistiges Eigentum dann landen würde...

Für genau sowas gibt es Lizenzen (GPL, LGPL, BSD, CC, ....). Damit hat man dann das recht auf seiner Seite. Aber mal davon abgesehen: Geistiges Eigentum ist sowieso per deutschen Urheberrecht geschützt (das sollte als deutscher Stattasbürger auch auf Lanzarote greifen, und falls nixcht: Urheberrecht in diversen Formen gibt's in beinahe jedem Staat).

Was du offenbar versuchst ist die Vermeidung von "Raubkopien". Aber auch dagegen ist kein Kraut gewachsen.

[gaert]

Für den produktiven Einsatz (später) würde ich allerdings eine dedizierte Hardware empfehlen - muss nichts großartiges sein, aber zuverlässig. EDOMI braucht wenig Ressourcen und könnte prinzipiell auch auf einem Raspi laufen (ungetestet). Ich habe als OS CentOS 6.5 in der Minimalinstallation gewählt und alle überflüssigen Dienste entfernt. Demnächst werde ich noch mit ArchLinux experimentieren - der Grundgedanke bei der Entwicklung war nämlich, dass EDOMI später quasi "embedded" laufen soll - ähnlich wie der HS. Sprich: Kleine schwarze Schachtel mit 2 Anschlüssen (LAN und Strom)

Im OS werden sämtliche Logs deaktiviert usw., EDOMI verwaltet sich selbst, räumt auf, macht Backups etc.

[gaert]

Was du offenbar versuchst ist die Vermeidung von "Raubkopien". Aber auch dagegen ist kein Kraut gewachsen.

So ist es... Andererseits: Was soll's Ich will mit EDOMI nicht reich werden - ich würde mich aber freuen, wenn das Progrämmchen in Zukunft viele KNX-Hütten steuert.

Nur am Rande: Meine Busteilnehmer sind allesamt auf "dumm" programmiert, d.h. untereinander kommunizieren die Gerätschaften rein gar nicht. Die gesamte "Logik" übernimmt EDOMI - selbst ein noch so trivialer "Lichtschalter" sendet nur seine GA, aber niemand außer EDOMI lauscht auf diese GA.

Wenn EDOMI mal streikt, ist's dunkel - schon klar. Aber gerade hier lag ja meine Motivation in Richtung möglichst robuster Programmierung und Absicherung. Wenn die Hardware in Flammen aufgeht habe ich allerdings Pech gehabt... Übrigens habe ich ein zweites identisches System im Schrank - für den Fall der Fälle Plug and Play...

[tuxedo]

So ist es... Andererseits: Was soll's Ich will mit EDOMI nicht reich werden - ich würde mich aber freuen, wenn das Progrämmchen in Zukunft viele KNX-Hütten steuert.

Dann lizensiere alles mit GPL und mach den Source komplett öffentlich. Damit verbleiben die Rechte beim Source selbst. Somit hat jeder immer freien Zugriff für auf die Quellen/das Programm und zwar für alle Zeit.

Das schließt aber nicht aus, dass eine Firma daherkommt, EDOMI auf eigene Hardware packt und ein Gesamtpaket verkauft. Nur muss diese Firma dann den Source ebenfalls offenlegen und auch bekannt geben dass sie EDOMI drauf haben.

Nur am Rande: Meine Busteilnehmer sind allesamt auf "dumm" programmiert, d.h. untereinander kommunizieren die Gerätschaften rein gar nicht. Die gesamte "Logik" übernimmt EDOMI - selbst ein noch so trivialer "Lichtschalter" sendet nur seine GA, aber niemand außer EDOMI lauscht auf diese GA.

Das ist ein interessanter Ansatz. Da würde mich deine GA-Struktur interessieren.

Wenn EDOMI mal streikt, ist's dunkel - schon klar. Aber gerade hier lag ja meine Motivation in Richtung möglichst robuster Programmierung und Absicherung. Wenn die Hardware in Flammen aufgeht habe ich allerdings Pech gehabt... Übrigens habe ich ein zweites identisches System im Schrank - für den Fall der Fälle Plug and Play...

Klassicher Single-Point-of-Failure. Aber dafür hat man die gesamte Logik auch zentral und übersichtlich und muss nicht mehrere Geräteeinstellungen gleichzeitig betrachten um das daraus resultierende Logik-Ergebnis zu verstehen.

[EPIX]

langsam werd' ich aber neugierig

- oder es wird mir ein bisserl unheimlich: Die Macht auf deiner Seite du hast?

Das ganze Projekt als 1-Mann-Show in 3 Jahren??!!
Alle Achtung - du hast offenbar wenig Hunger & Schlafbedürfniss

[coliflower]

Nur am Rande: Meine Busteilnehmer sind allesamt auf "dumm" programmiert, d.h. untereinander kommunizieren die Gerätschaften rein gar nicht. Die gesamte "Logik" übernimmt EDOMI - selbst ein noch so trivialer "Lichtschalter" sendet nur seine GA, aber niemand außer EDOMI lauscht auf diese GA.

Ist die „dumme“ Programmierung eine Voraussetzung oder funktioniert es auch „parallel“ ?

Alles in einer Box hat schon einen gewissen Charme, wenn mann eine zweite Box up-to-date hat ;-)
Kann man hier auch zwei „Boxen“ redundant betreiben die sich in Zeitabstand „x“ synchronisieren ?

[gaert]

Die "dumme Programmierung" ist natürlich keine Voraussetzung - EDOMI verhält sich wie jeder andere Busteilnehmer auch. Mir gefällt dieser zentrale Ansatz nunmal besser, es ist übersichtlicher und viel einfacher zu verwalten. In Zeiten moderner Hardware/Software ist die Ausfallwahrscheinlichkeit m.E. relativ gering - die Vorteile überwiegen für mich deutlich! Wenn mir ein Schaltaktor abraucht, sitze ich ggf. auch im Dunkeln. Klar, die anderen Aktoren funktionieren dann noch - aber ruhig schlafen könnte ich dann trotzdem nicht...

Eine 2. "Box" als Online-Fallback ist so nicht vorgesehen, aber machbar ist alles... Bislang habe ich noch keinen Bedarf verspürt: Wenn das System mal ausfallen sollte muss ich 3 Minuten opfern und das Ersatzsystem anschließen (sind ja nur 2 Stecker). Aber wie gesagt: Prinzipiell wäre es eine Überlegung wert, eine entsprechende Synchronisation etc. zu implementieren.

Das Projekt ist tatsächlich eine One-Man-Show Ich muss aber dazu sagen, dass ich quasi im Ruhestand bin - Zeit habe ich also genug. Sonst wäre das alles nicht in 3 Jahren zu schaffen gewesen Programmieren ist/war übrigens mein(e) Beruf(ung)...

[gaert]

lDie Macht auf deiner Seite du hast?

Ich zwinge ja niemanden... Und die Quelltexte liegen (später) wahrscheinlich offen, von wegen Backdoors usw.

[coliflower]

Wenn man sich deine Videos anschaut, dann eher Berufung ;-)

[coliflower]

Aber wie gesagt: Prinzipiell wäre es eine Überlegung wert, eine entsprechende Synchronisation etc. zu implementieren.

Ja, wäre sicher ein nettes Add-on, wenn die eine BOX ein „NOK“ sendet oder gar nichts, dass dann die zweite Box die Arbeit übernimmt - vor allem wenn man (länger) nicht anwesend ist … aber wie schon erwähnt, du hast vorher viele anderen Themen die eine hohe Priorität haben :-)

[gaert]

Wird bestimmt irgendwann kommen... EDOMI sendet ohnehin bei Bedarf einen "Heartbeat" auf den Bus (oder auch per HTTP), z.B. um einen entsprechenden Aktor (Treppenhauslicht) zu retriggern - wenn der Heartbeat ausbleibt, könnte dann z.B. ne Tröte tröten Dieser einfache Mechanismus überwacht sowohl die Funktion von EDOMI, als auch die Bus-Kommunikation.

Das Ganze würde natürlich auch mit einer einfachen Logik zu machen sein (HS) - ich habe diesen Heartbeat aber "hart" implementiert, um wirklich alle Faktoren zu berücksichtigen: Theoretisch könnte es ja sein, dass die Logik noch funktioniert, während andere wichtige Programmteile abgestürzt sind. Dies ist zwar äußerst unwahrscheinlich, da EDOMI sich komplett selbst überwacht und bei Bedarf neu starten würde - aber man kann ja nie wissen Die OS-Schicht könnte ja theoretisch auch mal versagen...

[MarkusS]

Wie gut das "verschleiern" selbst in einem "abgeschlossenen Betriebssystem" funktioniert, sieht man am Beispiel HS.

Naja. Da muss man dem HS allerdings zugute halten dass da entweder der dümmste anzunehmende Verschleierer am Werk war oder es ging nur darum, eine Proforma-Sicherung einzubauen um ggf. vor Gericht argumentieren zu können dass ein Schutz umgangen wurde wodurch man schnell in die Gefilde des Strafrechts kommt. Den HS hätte man mit sehr wenig Aufwand mehr deutlich dichter machen können.

Aber egal was man macht, irgendwo an irgendeiner Stelle im System liegt zu einem bestimmten Zeitpunkt quasi lesbarer, ausführbarer Code. Die Frage ist immer nur wie clever der auf der Gegenseite ist.

Ich vermute mal dass man bei Bosch und VW auch gerade von einer Krisensitzung in die nächste hetzt nachdem ein cleveres Kerlchen im Alleingang die Software von einem Motorsteuergerät von denen runtergezogen, auseinandergenommen und die Erkenntnisse veröffentlicht hat http://www.heise.de/newsticker/meldu...n-3056438.html - und ohne dem Edomi-Macher was Schlechtes nachsagen zu wollen: Ich gehe mal davon aus dass bei VW und Bosch deutlich mehr Ressourcen am Start sind die sich Gedanken gemacht haben wie sie ihr System dicht kriegen.

Das schärfste Schwert gegen "Raubmordkopierer" ist am Ende des Tages das Recht. Und dafür gibt es je nach Geschmack Lizenzmodelle noch und nöcher, ob das nun die GPL ist oder irgendwas furchtbar restriktives aus einer Großkanzlei.

Wenn man will dass sich möglichst viele Leute damit beschäftigen und das weitertreiben dann kommt man an irgendwas opensourcigem nur schwer vorbei - was nicht bedeutet dass man das nicht trotzdem für Geld verkaufen kann, Asterisk ist dafür ein Beispiel oder um in der Branche zu bleiben das Wiregate (wobei man dort mittlerweile die Weichen hin zu closedsource zu stellen scheint).

Während der "Markt" den etablierten Firmen einen gewissen Vertrauensvorschuss gibt bez. langfristiger Verfügbarkeit und Support ist das bei Projekten aus Onemanshows so eine Sache wenn da nicht offene Komponenten drin sind. Wenn der programmierende Privatier morgen beschliesst dass er fürderhin als nichtprogrammierender Eremit in einer Jurte in der östlichen Mongolei leben will (was selbstverständlich sein gutes Recht wäre) dann schauen die Nutzer halt etwas doof ins Gelände.

[gaert]

Hier mal ein Auszug aus einem typischen KO/GA-Log (gekürzt)

Bildschirmfoto 2015-12-29 um 11.53.37.png Bildschirmfoto 2015-12-29 um 11.53.55.png