Hallo, ich bin schon seit längerem dabei, in meiner wohnung mehrere Controllerbords zu verbauen, diese werden bei mir meist eingesetzt um z.b. RGB|LED leuchten|Stripes zu Steuern, habe im Wohnzimmer küche und Bad zusammen ca. 50m verbaut. Die Bords haben ein Ethernet Modul und arbeiten auf Basis eines ATMega8 zusätzlich zur Steurung der RGB Strips ist ein Temperatur Sensor verbaut, ein lichtsensor, ein RTC Modul und ein Bewegungsmelder .. . Aktuell werden die Kontroller hauptsöchlich über eine Billige IR Fernbedingung gestuert, diese waren bei den LED Stips dabei 5m = 1 Fernbedienung also habe ich 10 stück davon, und warum wegwerfen, das Ethernet modul, wird aktuell noch nicht wirklich benutzt, auf 2 Controllern habe ich da einen kleinen webserver am laufen der einem die werte für licht und Temp anzeigt, sowie sie eingestellt lichtfarbe. Soviel erstmal zum ist zustand. ich würde nun gerne anfangen die ganzen Controller zu vernetzen, und zwar möglichst per Kabel. Warum per Kabel? ganz einfach Kabel sind und werden vermutlich auch die Störunempfindlichste art bleiben Daten zu übertragen. zudem sind Arduinos bzw. ATMEga auch einfach, einfacher per Kabel anzubinden zudem muss man sich keine Sorgen bezüglich der Sicherheit machen. Als Server|Zentrale würde ich mein NAS Nehmen, dieses ist ein Linux PC auf dem Eh schon eine MySQL Datenbank läuft und ständig im betrieb ist. zusätzlich könnten diese aufgabe auch die Zahlreichen PIs dieses die ich Verbaut habe (Kodi) das wäre auch gleich ein weitere Art der Bedienung über ein Selbstgeschriebenes Kodi AddOn die Zentrale Frage nun was nutzte ich als Kommunikations Standard, es gibt ja zahlreiche Standards aber welchen haltet ihr als geeigneten für mein Vorhaben? Funkstandards gibt es genug aber als Kabelgebundenen habe ich bisher nur KMX gefunden ... es macht nach meiner auffassung sin, auf ein bestehendes system zu setzen, damit man auch fremdhardware einsetzen könnte. Könnt ihr mir da ein Paar Tipps geben?
Sascha F. schrieb: > unkstandards gibt es genug aber als Kabelgebundenen habe > ich bisher nur KMX gefunden ... es macht nach meiner auffassung sin, auf > ein bestehendes system zu setzen, damit man auch fremdhardware einsetzen > könnte. Ich denke mal du meinst KNX? Korrigiere mich wenn ich falsch liege: Aber wenn du auf einen Linux Server zugreifen willst worauf eine MySQL-Datenbank läuft, dann würde es sich doch anbieten TCPI/UDP zu verwenden oder Widerspricht das den Sicherheitsanforderungen.
Wenn du auf deine gestehende Netzwerkstruktur zurückgreifen willst: UDP, MQTT ,... Wenn ein eigenes Netz aufgebaut werden soll: RS485, CAN, CANopen, ... Christian_RX7
Nein, das wiederspricht nicht den Sicherheitsanforderungen, TCP/IP bzw. UDP hätte ich sowieso gedacht, die frage richtete sich eigentlich nach dem zu verwendeten Protokoll, klar kann ich einfach irgendwelche TCP/IP Strings durchs Netz schicken und dann am Controller interpretieren, so in etwa mache ich das Test weise aktuell ja, nur Anschluss von Fremd Hardware wird dann schwierig. hatte die Hoffnung das es dafür schon irgendwelche Protokolle oder sogar Libs gibt. ich wollte / würde gerne verhindern das RAD neu zu erfinden.
Christian K. schrieb: > Wenn du auf deine gestehende Netzwerkstruktur zurückgreifen > willst: UDP, > MQTT ,... > Wenn ein eigenes Netz aufgebaut werden soll: RS485, CAN, CANopen, ... > > Christian_RX7 also ich würde am liebsten mein Normales Netzwerk nutzen also std. 1000 MBit Ethernet.
Sascha F. schrieb: > würde am liebsten mein Normales Netzwerk nutzen Dann nimm MQTT! Das ist auf den ESP8266 häufig im Einsatz.
Sascha F. schrieb: > ... nur Anschluss von Fremd Hardware wird dann schwierig. Dann guck dir mal openHAB und MQTT (z.B. mit Mosquitto) an. Das ist auf solche Vielfältigkeit sozusagen spezialisiert.
Hört sich ganz gut an. Aber warum jedem Knoten einen RTC spendieren wenn du doch eh über NTP/PTP kommen kannst. Wäre das nicht ein wenig günstiger für dich?
Dennis X. schrieb: > Hört sich ganz gut an. Aber warum jedem Knoten einen RTC > spendieren wenn > du doch eh über NTP/PTP kommen kannst. Wäre das nicht ein wenig > günstiger für dich? das mit dem RTC hat einen recht einfachen Grund, wird der Controller aus irgendeinem Grund vom Server / Netzwerk getrennt, so kann er dennnoch weiterarbeiten, ich benutze das vorrangig zum schalten, im Badezimmer wird z.b. in der Zeit zwischen 23:00 - 06:00 uhr das licht beim erkennen einer bewegung leicht und langsam hochgedimmt bis etwar 150 R B & G = 0 so wird man nicht gleich hell wach wenn man nachts doch mal aufs klo muss :-) könnte man sich vermutlich aber auch sparen, wenn man etwas gehirnschmalz investiert. nur bei knapp 2 euro Pro RTC war das jetzt kein wirklicher Kosten Killer :-) Aber bisher laufen meine Controller ja Rel. Autark, so das ich das RTC schon brauchte ...
Wolfgang schrieb: > Sascha F. schrieb: >> ... nur Anschluss von Fremd Hardware wird dann schwierig. > > Dann guck dir mal openHAB und MQTT (z.B. mit Mosquitto) an. Das ist auf > solche Vielfältigkeit sozusagen spezialisiert. MQTT ziehe ich mir gerade rein, habe geseehn gibt sogar ne Arduino Lib dafür ... Schaut auf den Ersten blick vielversprechend zu sein, kann aber noch nichts finales sagen :)
Sascha F. schrieb: > kann er dennnoch weiterarbeiten, ich benutze das vorrangig zum schalten, > im Badezimmer wird z.b. in der Zeit zwischen 23:00 - 06:00 uhr das licht Wen interessiert dabei die absolute Zeit - es kommt auf die Raumhelligkeit drauf an, d.h. das Ding müsste mindestens den Sonnenstand kennen oder eben selber einen Helligkeitssensor besitzen ;-)
Wolfgang schrieb: > Wen interessiert dabei die absolute Zeit - es kommt auf die > Raumhelligkeit drauf an, d.h. das Ding müsste mindestens den Sonnenstand > kennen oder eben selber einen Helligkeitssensor besitzen ;-) naja die abslute zeit ist schon wichtig, zumindest im bade zimmer, da ich leider kein richtiges Fenster habe, nur so eine Scheibe rüber ins schlaf zimmer ist es im Bad eigentlich immer fast Dunkel, die werte schwanken in einem sehr kleinen Bereich, es lässt sich daher nicht wirklich bestimmen. zudem soll sich das licht tagsüber wenn man ins Bad geht anders verhalten Tagsüber habe ich fast Weißes licht bei fast voller stärke ... nachts nur ca. 150 rot tagsüber soll das licht auch nicht langsam hoch dimmen sondern schnell :-) wie gesagt, wirklich nötig darüber kann man streiten, aber den neuen Controller habe ich so aufgebaut das man ihn quasi universell einsetzen kann, und die zeit zu kennen ist fast immer gut :-) und bei 2 euro, was solls zudem kann man die Module Stecken, also wenn ich es doch mal pertu nicht will kann ich das Modul anziehen.
Sascha F. schrieb: > zudem soll sich das licht tagsüber wenn man ins Bad geht anders > verhalten von was machst du die Tag/Nacht Umschaltung abhängig? -Uhrzeit (Sommer/Winterzeit) -Außenhelligkeit -Sonnenhöhe (Elevation) oder eine Kombination dieser Werte um das synchron uns überschaubar zu haben ist einer Serverlösung, die allen Teilnehmern die Tag/Nacht Information liefert am einfachsten. Bei mir ist ein eine Kombination aller drei mit unterschiedlichen Schwellen bei Anwesenheit und Abwesenheit.
Volle schrieb: > von was machst du die Tag/Nacht Umschaltung abhängig? > -Uhrzeit (Sommer/Winterzeit) > -Außenhelligkeit > -Sonnenhöhe (Elevation) > oder eine Kombination dieser Werte > > um das synchron uns überschaubar zu haben ist einer Serverlösung, die > allen Teilnehmern die Tag/Nacht Information liefert am einfachsten. > > Bei mir ist ein eine Kombination aller drei mit unterschiedlichen > Schwellen bei Anwesenheit und Abwesenheit. Aktuell wirklich nur anhand der zeit, ich weiß ja wann ich / wir ins Bett gehen, zumindest Durchschnittswerte .. in diesem Zeitraum ist aktuell für den Controller Nacht, das Serverseitig zu lösen, macht in jeden Fall sin, aber da bin ich ja jetzt erst angekommen.
KNX ist mit seinen 9,6 kBit halt sehr einfach auch per Software zu erledigen auch der Teil mit der Checksumme. CAN würde eben einen uC mit CAN Controller externen oder internen CAN Treiber erfordern dort gibt aber wegen der ggf mehrmaligen Neusynchronisierung im Paket weniger Probleme und mann muss sich um viel weniger kümmern, wenn man alles eingerichtet hat, muss man nur die Daten an den CAN Controller übergeben welcher sich um alles kümmert.
Thomas O. schrieb: > KNX ist mit seinen 9,6 kBit halt sehr einfach auch per Software zu Er will aber: Sascha F. schrieb: > also std. 1000 MBit Ethernet. auch wenn das dann Stromfresser werden. aswwwer
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.