Edomi

[NetFritz]

Hallo
Tolles Projekt hast Du da entwickelt.

@SeatSLF
Raspberrys könnte man sich noch und nöcher hinlegen, die SD karten sind der Schwachpunkt

Nein der Schwachpunkt des RPi ist die Stromversorgung.
Seit ich meinen RPi mit einer Powerbank betreibe ist er noch nicht wieder abgestürzt.(jetzt ca. 9Monate Betrieb)
Vorher musste ich alle 2-4Wochen die SD neu bespielen.

Auch ich würde EDOMI gerne auf einem Raspberry Pi 2 ausprobieren.
Gruß NetFritz

[SeatSLF]

Raspberrys könnte man sich noch und nöcher hinlegen, die SD karten sind der Schwachpunkt

[DiMa]

Bin auch gerade mit den Videos durch: Wow!

[2Fast4You78]

Puh.. Ziemlich coole Geschichte dein EDOMI.
Ich würde es ja gerne mal auf meinen Raspi2 packen und testen. Mich würde mal interessieren inwiefern ein Endkunde der gerade so ein paar Zeilen HTML beherrscht damit klar kommt.
Smarthome.py ist schon ganz nützlich und sicherlich auch SmartVISU eine tolle Sache.. Allerdings sieht es da doch deutlich leichter aus.. Zumal ich bei Smarthome.py den Logikeditor vermisse der bei dir dabei ist.. Und auch noch Live..

Jetzt lass dich aber nicht von uns abhalten. Sieh zu das wir da mal teilhaben dürfen.. Wie auch immer du das anstellst..

[pauly]

- ...
- Logik-Debugging per Live-Ansicht (man kann es nicht oft genug betonen...)
- ...

Schon allein dieses Feature würde meinen Abschiedsschmerz vom HS mehr als eliminieren!

[cocoon]

Also ich sehe EDOMI als HS Killer.
Das ganze als Raspberry Image und man hat die besagte kleine schwarze Kiste mit LAN und Strom.
Ein Backup wäre ein leichtes und die Hardware kann man sich aufgrund der niedrigen Kosten als Backup hinlegen.
Ich bin wirklich begeistert.

[gaert]

Die m.E. wichtigsten Unterschiede zum HS (abgesehen von den Kosten):

- EDOMI läuft komplett im Browser
- es gibt zwar weniger Funktionalität im Detail (ISDN, etc.), dafür aber in der Praxis nützliche Dinge (Fritzbox, IR-Trans, etc.)
- die Visu ist einfach um Welten besser und moderner (Animationen, alle Parameter per KO steuerbar, Soundausgabe, und vieles mehr)
- an vielen Stellen ist die Konfiguration wesentlich einfacher, da auf das wesentliche reduziert
- viele Details habe ich am Einsatz in der Praxis orientiert, z.B. werden die Kamerabilder aus dem MJPEG-Stream gezogen, gecached (damit bei vielen Clients die Kamera nicht überfordert ist), natürlich kann auch per Internet auf die Bilder zugegriffen werden (ohne Umwege)
- die Speicherkapazität ist "unbegrenzt"
- alle Archivdaten sind frei zugänglich (SQL)
- die Logikbausteine lassen sich relativ einfach erstellen und bearbeiten
- Logik-Debugging per Live-Ansicht (man kann es nicht oft genug betonen...)
- uvm. - die Liste sollte gar nicht so lang werden

[gaert]

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.

Absolut richtig - es gibt sogar schon Pläne in diese Richtung Aber im Ernst: Der Opensource-Gedanke ist durchaus in meinem Sinne. Nur möchte ich nach Möglichkeit vermeiden, dass jemand Teile meiner Lösungen klaut und daraus ein kommerzielles Produkt generiert. Im Detail steckt eine Menge Gehirnschmalz in EDOMI, vor allem was die Umsetzung der Logik-Engine betrifft (fast schon patentwürdig). Die GUI usw. ist sicherlich keinen Innovationspreis wert - das können andere vermutlich noch besser machen, auch wenn dies eigentlich die meiste Zeit verschlungen hat... Es begann mit einem leeren "Texteditor-Fenster" - alles Handarbeit.

[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

[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]

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...

[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 :-)

[coliflower]

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

[gaert]

lDie Macht auf deiner Seite du hast?

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

[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)...