Mehrere FHEM im Netzwer... und dann einen Zentralen FHEM?

[MiilaMaheAedOU]

Guten Tag,

also ich bin Open Source Entwicklerin, arbeite seit 1999 mit Debian GNU/Linux (Slink 2.1), enwickle auch Hardware (ARM basierend und mit CAN) und nun habe ich seit 2014 eine experimentelle BioFarm in Miila/Estland im Aufbau...

So, nun benötige ich mehr als 300 Sensoren und Aktoren dafür und werde mir natürlich die Hardware selber bauen.

Also in Frage kommen

1) Raspberry PI 3

2) Texas Instruments Sitara mit 3 CAN ports, Ethernet und Display

Leztere müßte von mir komplett entwickelt werden, bedeutet aber auch, das er stricksten Automotive/MIL standards entsprechen würde, denn in Estland haben wir schon mal -30 bis -40 Grad Celsius...

Wie dem auch sei, ich habe gesehen das FHEM kein CAN Modul (CANopen) hat, weshalb ich vorhabe dies zu entwickeln.

OK, nun ist es so, das ich die "Controll Computer" (also Wall-Mounted embedded PC) per Objekt haben will, also

1) Haus
2) Werkstatt
3) 3x Gewächshaus
4) 4x Earthstorrage
5) Stall
6) Energieversorgung (4 Kleinwindanlagen, 3 -6 Solaranlagen, Batterien, Stromgenerator)
7) Wetterstation
Aussenanlage
9) Wald
...

Das ganze befindet sich innerhalb meines Farm-Netzwerks welches lediglich über einen 4G Router mit bizzarer privater IP am Internet haengt.

Gut, die einzelnen Controller sammeln die Infos und sollen sie an einen Intranet Server senden, der diese in meiner PostgreSQL speicher.

Dann will ich eine neunen Host einrichten, wie z.b. https://fhem.miila-mahe-aed.eu/ über den ich Daten öffentlich oder privat haben kann.

So, nun die Software entwicklung:

Das interface der Controll Computer sollt sowas wie die FHEM FLOORPLAN module sein, das ist intuitiv und sieht auch optisch cool aus, obwohl ich seit 40 Jahren Star Trek Fan bin...  LCARS ist cool!

Nunja, ich will nicht auf alle Controll Computer einzeln zugreifen, womit ich auf meinem Intranet Server eine FHEM instanz benötige, die auf alles zugreifen kann...

Eine copie davon muss auf meinem öffentlich Webserver sein...

Frage:

Ist dies mit FHEM technisch realisierbar und was für Config änderungen muessen da gemacht werden?

Anm.:  Ich kann KEINE andere Datenbank als PostgreSQL verwenden, da ich ansonnsten die naechsten 10 Jahre mit reprogrammierung von einigen 100 Applikationen beschaeftigt bin...  Abgesehen davon ist MySQL keine Löesung, sondern ein Zustand!

Gruesse und dank im voraus
Michelle

[MiilaMaheAedOU]

Habe noch was vergessen:

mein wichtigstes Modul was ich derzeit benötige ist für

https://www.miila-mahe-aed.eu/renewable_energies/energy_harvesting.php

denn das tägliche ablesen und datei abladen wird allmählich nervig.

[Beta-User]

Hallo Michelle,

willkommen im Forum!
Schönes "Projektchen" hast du da vor...

Vorab eine Warnung: Ich bin kein Software-Entwickler, habe auch keine Ahnung von Datenbanken und nur einen einzigen Rechner mit FHEM am laufen.

Grundsätzlich sollte das schon möglich sein, FHEM zur Unterstützung bzw. Visualisierung einzusetzen. Üblicherweise würde man diverse FHEM-Instanzen mit FHEM2FHEM oder RFHEM verbinden. Allerdings bin ich mir nicht so sicher, ob das die richtige Infrastruktur ist, um so ein Projekt umzusetzen.

Hier würde ich neben dem zentralen Steuerungsrechner (der mit FHEM laufen kann) das Konzept eventuell so gestalten, dass die Infos bzw. Schaltanweisungen zu mehr oder weniger entfernten Stationen eventuell auf andere Art und Weise ausgetauscht werden. Spontane Stichworte dazu wären MQTT und LoRa.

MQTT ist als robustes Protokoll mal entwickelt worden, um große verteilte Systeme zu überwachen und kann als Informationsquelle auch gut in FHEM genutzt werden.

Wenn Teilsysteme "nur" regelmäßig verhältnismäßig wenige Informationen senden sollen (alle 10 Min. Leistungsdaten von einem Energieerzeuger), könnte das auch über eine Microprozessor-basierte Lösung gehen. Über RFM95-LoRa-Module sollten sich auch über mehrere km solche Infos senden lassen, bei MySensors.org ist sowas jedenfalls in der Entwicklung. Auch hier ist die Einbindung in FHEM gut und einfach, dazu noch recht kostengünstig.

Bin mal gespannt, wie du das letztendlich lösen wirst!

Gruß, Beta-User

[MiilaMaheAedOU]

Hallo Beta-User

Grundsätzlich sollte das schon möglich sein, FHEM zur Unterstützung bzw. Visualisierung einzusetzen. Üblicherweise würde man diverse FHEM-Instanzen mit FHEM2FHEM oder RFHEM verbinden. Allerdings bin ich mir nicht so sicher, ob das die richtige Infrastruktur ist, um so ein Projekt umzusetzen.

Das sehe ich mir einfach mal an...

Hier würde ich neben dem zentralen Steuerungsrechner (der mit FHEM laufen kann) das Konzept eventuell so gestalten, dass die Infos bzw. Schaltanweisungen zu mehr oder weniger entfernten Stationen eventuell auf andere Art und Weise ausgetauscht werden. Spontane Stichworte dazu wären MQTT und LoRa.

MQTT ist als robustes Protokoll mal entwickelt worden, um große verteilte Systeme zu überwachen und kann als Informationsquelle auch gut in FHEM genutzt werden.

Wenn Teilsysteme "nur" regelmäßig verhältnismäßig wenige Informationen senden sollen (alle 10 Min. Leistungsdaten von einem Energieerzeuger), könnte das auch über eine Microprozessor-basierte Lösung gehen. Über RFM95-LoRa-Module sollten sich auch über mehrere km solche Infos senden lassen, bei MySensors.org ist sowas jedenfalls in der Entwicklung. Auch hier ist die Einbindung in FHEM gut und einfach, dazu noch recht kostengünstig.

Hmmm, es ist halt nur so, das ich eine nette Grafische Oberflaeche in den Controll Computern (entfernte Schaltzentralen) haben will, was ich schon selber programmiert habe, aber eben aufwendig ist, wenn es flexibel sein muss.  Denn in ein TFT ein Bild einblenden, Daten anzeigen und mit das resistive Touchscreen abfragen (kapazitive funktionieren nicht bei hoher Luftfeuchtigkeit oder -20 Grad Celsius) ist einfach, aber wenn Du jährlich ändeung am Gewächshaus vornimmst, dann ist das NERVIG.

Deswegen war meine Idee, auch auf den Controll Computern (entfernte Schaltzentralen) eben FHEM zu installieren.

So wie es aussieht muss ich das mal ausprobieren.

Bin mal gespannt, wie du das letztendlich lösen wirst!

Ich selber auch, denn derzeit (also dieses Jahr) war ich hoffnungslos überlastet und habe mal schlappe 13 kg verloren, bin also kein fettes Schwein mehr... ...nur noch gut ernährt!  Ein paar kg fehlen noch.

Gruesse
Michelle

[herrmannj]

Welchen Zeitplan hast du dir gesetzt ?

[Beta-User]

OK, Danke für die Rückmeldung.

Wenn du eh' an den entfernten Stationen eine neue Steuerungssoftware einsetzen willst, ist das was anderes. (Und das auch brauchst, für einfache Dinge reicht uU. auch was einfacheres, also eine Art Szenencontroller, ähnlich dem hier).

Ansonsten würde ich trotzdem nochmal das Stichwort MQTT in den Raum stellen - das erscheint mir auch beim Einsatz mehrerer FHEM-Rechner vor allem dann interessant, wenn die Kommunikation ggf. störanfällig ist. Vielleicht meldet sich hier noch jemand, der Erfahrung damit hat.

Das bietet ggf. auch eine einfache Möglichkeit, die bestehenden Stationen - die du ja bereits programmiert zu haben scheinst - recht einfach aufzubohren. Der vorhandene Code müßte dann halt um die MQTT-Kommunikation erweitert werden, aber dafür sollten für praktisch alle Plattformen schon libraries verfügbar sein.

Aber meistens führen mehrere Lösungen zum Ziel, mal sehen, was andere dazu denken .

[Thorsten Pferdekaemper]

Hi,
also beim ersten Lesen dachte ich mir: Scheiße, klingt das interessant. Ich fange gleich bei Dir an...
Wenn Du tatsächlich so gut bist, was Soft- und Hardware-Entwicklung betrifft, dann sollte das ganze mit FHEM gehen. Natürlich ist das ganze ziemlich groß, aber die einzelnen "Control Computer" müssen ja immer nur einen recht übersichtlichen Teilaspekt abdecken.
Allerdings habe ich nicht ganz verstanden, wie die Integration tatsächlich passieren soll. Entweder die einzelnen Control Computer schreiben mehr oder weniger direkt in die zentrale Datenbank und das zentrale FHEM holt die Daten irgendwie aus dieser Datenbank, oder das ganze läuft über das zentrale FHEM, welches in die Datenbank schreibt. Da kommt es ggf. auch darauf an, ob das zentrale FHEM auch irgendwas schalten können soll, oder eben nur Daten aufzeichnet.

Von wegen "nette Oberfläche" und FHEM gibt es immer wieder Diskussionen. Es gibt einige Leute, die der Meinung sind, dass das gerade die größte Schwäche in FHEM ist. Meiner Meinung nach ist die FHEMWEB-Oberfläche für Administratoren oder Entwickler richtig gut, aber nicht wirklich für "Endbenutzer" oder um mal schnell einen Überblick zu bekommen. Man kann natürlich mit Floorplan oder Tablet-UI einiges machen, aber über deren Flexibilität lässt sich auch wieder streiten. (Für Tablet-UI bin ich gerade dabei, was zu basteln, aber da bin ich erst am Anfang.)

Von wegen MQTT oder nicht: Mir ist nicht so ganz klar, was das in dem Fall bringen soll. Man müsste sowieso nochmal eine Schicht oben drauf packen, was man bei FHEM2FHEM oder RFHEM nicht braucht.

Gruß,
    Thorsten

[Beta-User]

Kurz, was die (vielleicht völlig verkehrte) Idee (eines derzeitigen Nichtanwenders dieser ganzen hier in Rede stehenden Technologien) in Richtung MQTT angeht:

- Das Protokoll ist dafür gemacht, auch auf Verbindungsabbrüche nicht gleich empfindlich zu reagieren - wie das bei RFHEM und FHEM2FHEM ist, kann ich nicht sagen. Es _könnte_ also robuster sein.
- MQTT als Kommunikationslayer läßt sich auch auf einfacheren Devices realisieren. Wenn man nicht (gleich) alles mit FHEM ausrüsten will, ist das evtl. als (übergangsweise) Erweiterungsmöglichkeit vorhandener Hardware eine _mögliche_ Lösung.

(Was mir beim Schreiben hier noch eingefallen ist: Hat man einen MQTT-Broker am laufen, kann man die Visualisierung evtl. auch auf andere Art machen, aber dazu habe ich außer dem Grundgedanken (und den vielleicht passenden Stichworten IOBroker oder nodered) nun gar keine weitere Idee). FHEM ist in dem Punkt grafische Gestaltung jedenfalls dem Hörensagen gegenüber nach anderen Lösungen im Hintertreffen, das ließe sich evtl. dadurch Umschiffen, dass man den Teil mit ganz anderen Tools löst.

Kann aber auch ganz falsch sein. Bin also schlicht gespannt, hier was neues zu lernen .

Gruß, Beta-User

[MiilaMaheAedOU]

Welchen Zeitplan hast du dir gesetzt ?

Mail 2017!  Örgs!

Nun wirds aber für mich dringend und ich muß mindestens meine Power Station bis April 2018 fertig bekommen

Benötige also erst mal den Controll-Computer und dann folgende Sensoren:

1) Batteriespannung  (24V)
2) Batterie Temperaturen (6x)
3) Ladestrom Victron Energy BlueSolar MPPT 150/85 (3x)
4) Ladestrom windMAX1000 -> iSTA-Breeze i-700 (2x)
5) Ladestrom windMAX2000 -> iSTA-Breeze i-2000 (2x)
6) Generator Ladestrom (Hatz Diesel 1,9kW 28V 68A)
7) Ferneinschaltung des Generators
Gesamtlaststrom =>1200A
9) Laststrom Carport 200A (sind eigentlich die beiden 12V/20A und 24V/60 Ladeggeräte fuer die Autos und meine beide E-Traktoren)
10) 4 Temperatursonden im 8-10m³ Erdwärmespeicher unter den Batterien (wird durch Überschußenergie aufgeladen sowie Compostheizung)
11) 2 Tempoeratursonden Compost
12) Flowsensor (Kobold, einfacher Schalter)
13) Xylem/Lowara EcoCirc D5vario Zirkulationspumpe
14) Temperatursensor im Batterie-Storrage
15) Außentemperatur (muss bis mindestens -40 Grad Celsius gehen)

Was ich noch benötige, später aber Objektbezogen einen eigenen Controll Computer bekommen wird, sind

A) Laststrom Haus (200A)
B) Laststrom Werkstatt (300A)
C) Laststrom Gewächshaus (200A)
D) Laststrom Earthstorrage (200A)

Ich hoffe, das ich nichts vergessen habe.

Oh doch, die Stromsensoren sollen definitiv keine Shuntwiderstaende sein sondern HAL-Sensoren

Grüße
Michelle

[CoolTux]

Wenn das erwähnte CANopen das selbe ist wie openHCAN dann ist bereits ein Modul in entwicklung. Der Guido würde sich über tatkräftige Unterstützung sehr freuen, er hat selber einen engen Zeitplan.


https://forum.fhem.de/index.php/topic,77854.0.html



Grüße

[Wernieman]

Was mir immer noch nicht klar ist:

- ist der entferne FHEM nur "Sammelrechner" oder "Steuerrechner" für die Clients? D.h. geht der Informationsfluß von den Clients zum Zentralserver oder geht es manchmal auch andersherum? Bzw. sind die Einzelrechner Eigensteuerfähig, d.h. machen alles selber, oder sammeln sie nur Daten und warten auf Zentrale Auswertung?

Je nach Datenflußrichtung gibt es dann unterschiedliche "Lösungen"

[GU!DO]

Hallo Michelle,

also, wie CoolTux schon geschrieben hat, bin ich (eigentlich muss man sagen sind CoolTux und ich) grad dabei openHCAN und FHEM zu verheiraten.

openHCAN ist ein Bussystem das zum Betrieb in Einfamilienhäusern entwickelt wurde. Die Standard Controller haben 16 Ein- und 12 Ausgänge.
Lassen sich aber mit minimalem Aufwand auf 8 Ein- und 20 Ausgänge umrüsten. Außerdem gibt es ein Multiplexer Modul, damit ist noch mehr drin.
Da die Controller aber sehr preiswert sind (Bauteilkosten ca. 30 EUR) habe ich das Modul nicht im Einsatz.

Die Controller basieren auf ATMega32 bzw. ATMega644 und kommunizieren über CAN Bus. Die einzelnen Controller lassen sich über den Bus sowohl konfigurieren, als auch updaten (Firmware).
Die Firmware und alle weiteren Tools sind in C programmiert.
Ich habe das System schon seit ca. 10 Jahren ohne jegliche Probleme im Einsatz - allerdings (bisher) noch nicht bei -40° Celisus. 

Falls das interessant klingt, kannst Du dich ja mal im Wiki umsehen: https://github.com/hcanIngo/openHCAN/wiki

Viele Grüße & gutes Gelingen

Guido

[MiilaMaheAedOU]

Was mir immer noch nicht klar ist:

- ist der entferne FHEM nur "Sammelrechner" oder "Steuerrechner" für die Clients? D.h. geht der Informationsfluß von den Clients zum Zentralserver oder geht es manchmal auch andersherum? Bzw. sind die Einzelrechner Eigensteuerfähig, d.h. machen alles selber, oder sammeln sie nur Daten und warten auf Zentrale Auswertung?

Je nach Datenflußrichtung gibt es dann unterschiedliche "Lösungen"

In erster Linie Steuerrechner, den ich auch vor Ort abrufen will und eventuell Änderungen vornehmen.
Also mit localem Webbrowser.

Wenn ich "zuhause" bin ist es ja kein Problem innerhalb meines Netzwerks auf die IP oder locale Domain zuzugreifen.

Und jetzt wirds kompliziert, denn ich will die Daten alle auf einem Zentralen Rechner haben um alles zusammen auswerten zu koennen...
Als 1zu1 Copie waehre ja genug.

Aber dann will ich auch die Möglichkeit haben, das ganze von der Antarktis, vom Mond oder vom Mars aus zu steuern.

Mein Root-Server steht derzeit in Nürnberg bei Hetzner wird aber noch nach Tallinn umziehen.
Die Frage ist nun, wie kann ich von ausserhalb meines Netzwerks das ganze administrieren oder öffentlich abrufen?

Wenn es nur um Statistiken und angucken geht, was bei mir los ist, kann das ganze ja passiv gemacht werden und mein Intranetserver kann die Daten ja per Upload auf meinem Root-Server replizieren...  Dann habe ich auch gleichzeitig ein Backup.

Nur in der anderen Richtung ist es kompliziert...

VPN Tunnel einrichten und das über GSM Netzwerk?
Mir graut bereits davor!

Gruesse
Michelle

[MiilaMaheAedOU]

N'Abend GU!DO,

Hallo Michelle,

also, wie CoolTux schon geschrieben hat, bin ich (eigentlich muss man sagen sind CoolTux und ich) grad dabei openHCAN und FHEM zu verheiraten.

Bin bereits am lesen des Topics...

openHCAN ist ein Bussystem das zum Betrieb in Einfamilienhäusern entwickelt wurde. Die Standard Controller haben 16 Ein- und 12 Ausgänge.
Lassen sich aber mit minimalem Aufwand auf 8 Ein- und 20 Ausgänge umrüsten. Außerdem gibt es ein Multiplexer Modul, damit ist noch mehr drin.
Da die Controller aber sehr preiswert sind (Bauteilkosten ca. 30 EUR) habe ich das Modul nicht im Einsatz.

Die Controller basieren auf ATMega32 bzw. ATMega644 und kommunizieren über CAN Bus. Die einzelnen Controller lassen sich über den Bus sowohl konfigurieren, als auch updaten (Firmware).

Die Firmware und alle weiteren Tools sind in C programmiert.
Ich habe das System schon seit ca. 10 Jahren ohne jegliche Probleme im Einsatz - allerdings (bisher) noch nicht bei -40° Celisus. 

Falls das interessant klingt, kannst Du dich ja mal im Wiki umsehen: https://github.com/hcanIngo/openHCAN/wiki

...und auch bereits hier am lesen.

Nunja, ich verwende das pure CANopen Protocol und vollstaendig Microcontroller mir Indistrie-Qualität, welche von -40°C bis +85 (105)°C aushalten. Estland ist hat weit oben im Norden...

Erfahrung habe ich mit dem NXP Cortex M0 LPC11C24 seit vielen Jahren (und er ist saubillig mit 1,2€/Stück, besonderst wenn man ein Rail mit 250Stück abnimmt) und die meisten chips haben nur einen Sensor dran...  Das teisterst daran ist meist der Sensor, wie ein HAL-Stomsensor oder Gas- oder Temperatur-Sensor.

Gut, hatte auch ein paar M0 welche ausschließlich GPO/GPI hatten.

Meine Frage ist zu Dir, wie weit ist openHCAN compatibel mit CANopen und industriellen Nodes?

Ich meine die sind ja genormt und ich gehe davon aus, das ihr eure eigene Norm geschrieben habt denn "H" bedeute ja so was wie "Home" richtig?

Mein CAN bus war/ist dafür ausgelegt, das ich jedes industrielle CAN kompatibel Gerät anschließen kann.

Von der Spezifikation bin ich auch kein Bit abgewichen.

Ich war bis 2012 Mitglied der CAN CIA und habe vor, wieder einzusteigen, aber erst brauch ich mein Haus, also ein Dach über dem Kopf, dann muss meine BioFarm laufen (ohne Moos nix Los) und dann kommen Elektronik- und IT Arbeitsplatz hinzu, welche ich definitiv ab Winter 2018/19 benötige weil ich sonst arbeitslos 4-5 Monate herumsitze.

Muss morgen früh wieder um 8 Uhr bei -5°C und 10cm Schnee raus, am nicht fertigen Wildschutzzaun weiterarbeiten.  Ist an den Pfosten nur provisorisch festgemacht und ich habe noch 550m vor mir...  um 16:00 ist es bereits so Dunkel, das man nichts mehr sieht!

Anm.: Wer nach Estland auswandern will:  Es gibt hier jede menge Grundstücke für weniger als 0,50€/m²... Habe mir 2,8ha für 5500€ gekrallt.

Gruesse und gute Nacht
Michelle

[GU!DO]

Hallo Michelle,

sorry, in der CAN Thematik stecke ich leider nicht sonderlich tief drin. Ggf könnte Ingo, der den Hauptteil der Entwicklung macht, weiterhelfen. Er hat das Projekt jedoch auch von Martin Haller übernommen. Oder Du fragst im Forum auf openHCAN.org nach. Dort ist zwar nicht sehr viel los, jedoch gehen Threads weiter in die Mailingliste und werden von allen gelesen.

Erstmal viel Erfolg beim Einzäunen. Die 50 ct. / m2 sind ja sehr verlockend, relativieren sich glaube ich jedoch sehr schnell durch die Heizkosten. 

Viele Grüße

Guido

[MiilaMaheAedOU]

Naja, kommt darauf an...

Bei 2,8ha hast Du meistens 2/3 Wald dabei und Du must nur sinnvoll fällen und natürlich aufforsten. dann mußte niemals zukaufen...

Ich heize entweder mit einem (genaugenommen theoretisch bis zu sechs) Riesen-Compost (80m³ Holzschnitzel) oder mit einem Rocket-Mass-Heater + Bufferspeicher...

Das Haus ist natürlich massiv aus Holz und hat ne Fußbodenheizung.

Wenn ich das Holz kaufen muss, komme ich mit gut 2,50€/Tag bei 80m² Loghaus Fläche hin...

Habe aber einen eigenen 5,6ha Wald, welcher erst vor 5 Jahre 80% gerodet und aufgeforstet wurde. Nun habe ich nur noch ein paar Mega-Birken rumstehen und 2 liegen, allesamt nicht unter 45cm Durchmesser und nicht unter 24m lang/hoch womit man ein paar Jahre heizen kann.



Das alles Messtechnischen zu erfassen erfordert ja auch FHEM... und ist dann nicht Off-Topic hier.
Vor allem sind das jede menge Sensoren und sonstwas.

Bin gerade am suchen nach geeigneter Hardware für die Controll-Computer.

Problem bereitet mir eigentlich nur das flache Gehäuse was man erst mal finden muß.
Sollte ein 10" Display aufnehmen können und einen Raspberry, Li-Poly Battery mit Protection und Ladechip oder Mini-ITX.
Vor allem muss es mit 24V DC (18-32V automotive) funktionieren.

Echt nervig... So wie es aussieht werde ich das Gehäuse aus Stahlblech schweißen was mich dann 10€ kostet und keine 100 für ein dummes Plastikgehäuse was auch nicht schöner aussieht.


Ehm Frage:

Gibt es auch FHEM Sticker ("FHEM inside") oder so?

[rudolfkoenig]

Gibt es auch FHEM Sticker ("FHEM inside") oder so?

fhem/docs/fhem.odg

[MiilaMaheAedOU]

Ehm?

[CoolTux]

do it yourself

[Morgennebel]

Hmmm, es ist halt nur so, das ich eine nette Grafische Oberflaeche in den Controll Computern (entfernte Schaltzentralen) haben will, was ich schon selber programmiert habe, aber eben aufwendig ist, wenn es flexibel sein muss.  Denn in ein TFT ein Bild einblenden, Daten anzeigen und mit das resistive Touchscreen abfragen (kapazitive funktionieren nicht bei hoher Luftfeuchtigkeit oder -20 Grad Celsius) ist einfach, aber wenn Du jährlich ändeung am Gewächshaus vornimmst, dann ist das NERVIG.

Was spricht denn gegen einen kleinen PC mit Display, der eine FHEM-Instanz, MQTT und einen Webbrowser fährt?

MQTT zum einsammeln der lokalen (näheren) Sensoren, ein FHEM zum einsammeln von MQTT und Weiterleitung an die Zentrale (FHEM2FHEM). Den Browser zum anzeigen des zentralen FHEM-Status mit LCARS oder wie auch immer...

Sollte was schnelleres und solideres als ein Pi sein (also mit eMMC/SSD-Speicher) - das wäre dann in jedem Fall performant. Die GUI wird dann einmal in der Zentrale definiert und steht überall zur Verfügung.

Mich würde dann irgendwann eher der Stromverbrauch der FHEM-Lösung beunruhigen. Offenbar bist Du ja autark aufgestellt, wie solide und sauber ist denn Deine Versorgungsspannung?

Ciao, -MN

[MiilaMaheAedOU]

Also ich HABE einen Server der permanent, also 24/7 läuft:  meinen Intranet Server!

Der soll ja auch von allen Controll Computern (Entfernte Steuerungen) die Daten zur zentralen Auswertung Empfangen.
Das Raid-1 mit der PostgreSQL Datenbank hat 1 TByte, was sehr gut ausreichen sollte. 

Der Intranet Server kann dann auch die Haup-Instanz von FHEM haben, da ich ja sowieso ein Intranet Webinterfache habe, mit dem ich auch meine Root-Server unn deren VHosts, Domains, Mailsevrer, etc., administrieren kann.  Ist also eine eierlegende Wollmilchsau!

Die Controll Computer in den einzelnen Objekten sollen ja jeweils nur das einzelne Object überwachen und steuern.
Deshalb benötigen die Controll Computer ja ein anständiges resistives touchscreen Display mit entsprechender Größe (10-12")

Gut, kann ein MiniITX einsetzen, nur die entsprechenden sind super teuer, speziell wenn man

1) DSI
2) 1-2 CAN
3) SPI
4) I2C
5) min 2x USB
6) RS-232
7) microSDHC
eventuell SATA

benötigt.  Hat halt den Vorteil, das man einfach ein standard Debian GNU/Linux draufklatschen kann.

Hatte mal (bezahlt) einen WindowManager geschrieben, der ausschliesslich ein Maschineninterface hatte, sprich, FHEM koennte man sogar dazu abwandeln, also nicht als Web-App sondern eben Desktop-App.

Irgendwie ist alles nicht das ware... Entweder kostengünstig und nicht vollständig oder eben vollständig und schweine teuer!

Eine MCU mit Peripherie und alles ist ja kein Problem, denn ich bin ja seit ewigkeiten Kunde bei allen möglichen Chip-Herstellern und Distributoren, aber so ein zwischending von SPS und PC zu designen ist halt nicht in einem Jahr und erst recht nicht alleine.

Speziell, wenn heutige MCUs FPBGAs mit 1000 und mehr Balls sind. Meine Wunsch/Traum MCU hat über 1600, ist allerdings eine Telekommunicatins MCU mit 100 Kernen und hat ein paar vollständige 16-Lane PCIe.  Könnte meine neue Workstation werden! 

[tik-tak-tok]

Hallo Michelle,

interessantes Projekt!
Kurze Frage: Wie weit sind deine "Außenstellen" denn von deiner "Zentrale" entfernt?
Ginge da etwas über ein kleines Richtfunk Netzwerk? Bestehen Sichtkontakte untereinander oder zur Zentrale?

So könntest du ein großes VLAN generieren und alle Nodes dort quasi mit reinpacken.

Grüße,
Mike

[MiilaMaheAedOU]

Der größte Abstand ist 200m.

Wenn ich unter 125 Nodes hätte und keine Object Controller (entfernte Steuerungen), währe es ja einfach!
mit CAN kann ich 1000m lange Leitungen haben und meine Nachbarn gleich mit kontrollieren

Ich hatte vor, parallel zum HD-PE Rohr und dem Stromkabel ein Leerrohr in das Erdreich hineinzulegen und fiberoptic einzuziehen.
ein Etherhent HUB mit 8 GBit Ports und zusätzlich 4 Fiber Ports kostet gerade mal 380€ und ein Fiber-Ethernet Adapter 70€.

Hatte die Firma auf der Hannover Messe 2017 kennen gelernt.

Somit währe das Basisnetzwerk schon mal da.

Richtfunk und auch WiFI-IP-Cams werde ich definitiv nicht verwenden, weil kriminelle Jammer verweden wenn Sie in alleinstehende Farmen und Häuser einbrechen...

Nunja, kann sein, das ich tatsaeclich ein MiniITX anstatt eines Pasbian/Banana verwende.
Nur die Sache mit dem CAN wird dann kompliziert und teuer.