HAUS - Control

[Feuerring]

Hallo zusammen,

bin gerade dabei meine derzeitige Haus-Steuerung zu überarbeiten,

die normale Verkabelung Licht / Steckdose ist klassisch und wird auch so bleiben,

es geht hauptsächlich um sonder Funktionen: Lüftungs-Anlage / Garten - Beleuchtung / Sonder-Beleuchtung / usw.

Derzeit mache ich das über einen erweiterten I2C-Bus, läuft auch seit Jahren stabil.
ich habe mich damals dafür entsieden, weil ich so Aktoren und Sensoren ohne zusätzlichen Aufwand ( Prozessor )
verwenden konnte ... das ganze System ist aber für meine jetzigen Ansprüche zu unflexibel,
da der Master (PC) alle abfragen und Steuerungen übernehmen muss und eine Erweiterung immer einen programmier Aufwand mit sich führt.

Derzeit ist mein Außen-Modul (Licht / Temp) ausgefallen, ist wohl Wasser eingedrungen ...

Jetzt plane ich ein Multi-Master System was offen ist, Module können ferngesteuert aber auch austakt arbeiten.

z.B.

Ein Relais-Modul mit 4 Ausgängen (Relais) kann klassisch direkt gesteuert werden.

Ausgänge können Gruppen zugeordnet werden, diese können dann über Broadcast Modulübergreifend gesteuert / geschaltet werden.
diese Gruppen können aber auch Modul internen Schalt z.B. Zeit Profilen zugeordnet werden ...

Die Schalt-Module können so auch weitgehend austakt als intelligente Schaltuhr arbeiten ...

Baumarkt Funk-Steckdosen steuere ich derzeit über einen I2C-Funk-Sender, dieser wird dann genauso als Modul-Aufgebaut,
einzelne Funk-Steckdosen können dann dort als Ausgang definiert werden und ebenfalls Gruppen oder Schalt-Profilen zugeordnet werden.

Die Gruppen können auch anderen Gruppen zugeordnet werden, so ist es dann möglich die Gruppe der Weihnachts-Beleuchtung egal ob Funk oder Relais,
über die Gruppe Nacht-Beleuchtung mit zu steuern, aber auch jederzeit AUS oder EIN oder einer anderen Gruppe / Schalt-Profil zu zuordnen ...

Die Lüftungs-Steuerung (Wärme-Rückgewinnung) soll ebenfalls selbstständig laufen und nur noch über den BUS in Ihrer Funktion beeinflusst werden können.

Das Multi-Master-Protokoll auf dem Bus wird RS232 mit ASCII sein, so kann ich dieses auch ohne Probleme über Socket / GSM übertragen.

Der PC bekommt eine Master-Control Funktion, und kann die Module zusätzlich steuern / Steuer-Profile / Gruppenzuordnungen nach Jahreszeit anpassen
natürlich auch spezielle Gruppen Schalt-Funktionen übernehmen ...

Alle Module antworten auf ein Kommando außer bei Broadcast ( Adresse=00 ), jedes Modul kann auch Master sein ( Sensor Abfrage ) und bekommt ein Zeitfenster innerhalb einer Minute,
um Kollisionen so weitgehend zu vermeiden ... auf dem BUS wird aber durch die austakte Funktion der Module nur sehr wenig los sein ...

Module mit speziellen internen Schlafprofilen ( ZEIT / Helligkeit / Temperaturen ) können so auch über zugeordnete Gruppen, andere Module als Master mit gleichen Gruppen mit gesteuert werden.

Bin noch am zusammentragen und planen, werde aber auch hier über mein Projekt berichten

[Feuerring]

Hallo zusammen,

habe mal angefangen einen NANO zu programmieren um diesen als Modul MCU zu nutzen,
durch die begrenze Speicher SRAM / EEPROM habe ich die Anzahl der Gruppen auf 96 mit je 8 Register eingeschränkt.

Register-Gruppenzuordnung habe ich im EEPROM abgelegt und ist so bis zu einer gezielten Änderung fest,
die Modul-Adresse kann ebenso im EEPROM per Befehl abgespeichert werden.

Die derzeitige Protokoll-Beschreibung habe ich mal angehängt und mal ein Beispiel wie man mit den Gruppen-Funktion Modul übergreifend recht komplexe Verschaltungen realisieren kann.

Jedes Modul welches über Broadcast zugeordnete Gruppen und dessen Wert ändern darf,
bekommt ein Zeitfenster innerhalb einer Minute wo es senden darf, die interne UHR bzw. Sekunden-Zähler wird über den Control-Master per Timestamp synchronisiert.

[Feuerring]

Aus meiner Erfahrung im Industriebereich reicht Summe-1 völlig aus!

Habe ich gestern auch so fertig gemacht, CS ist nun zwingend ...das mit dem optional habe ich sein gelassen ...

CS = Byte(1) + Byte(2) + Byte(x) + Anzahl der Bytes (Überlauf bei 255)

#zzaakk|F1|F2|F3|....|Fx [30] CS [13]

[] = chr$

Datensätze wo die CS nicht stimmt, länger als 100 Zeichen oder der Header nicht plausibel ist, werden ohne Rückmeldung verworfen,
ist in meiner Haus-Steuerung auch nicht so dramatisch, da die Daten alle 60 Sekunden neu gesendet werden ...

Mein Steuer-PC der 24x7 läuft, wird ein Teil von Steueraufgaben bekommen, hauptsächlich komplexe Schaltuhr und BUS-Sniffer (Loger)

Ein Modul was im BUS neu gestartet oder eingeschaltet wird, wartet immer erst auf ein Zeitsync, welches von einem Modul alle 60 Sekunden generiert wird,
im Normalfall übernimmt das der PC, kommt nach 120 Sekunden kein Sync, übernimmt diese Funktion ein anderes Modul automatisch,
so ist immer gewährleistet das die Module Ihre feste Sende Zeit haben und es so zu keinen Kollisionen kommt kann,
Die Module Synchronisieren über dieses Sync-Signal ihre internen Sekunden-Zähler und passen entsprechend den Vorteiler automatisch an ...
Möchte man Module auslesen oder programmieren, kann man den BUS reservieren ... Kommando(#zzaa10)
Daraufhin stellen alle Module im BUS ihre internen Funktionen ein und warten nur noch zu 100% auf Kommandos im BUS, sobald wieder ein Zeit-Sync kommt,
arbeiten die Module wieder wie gehabt ...

[Peter(TOO)]

Hallo Ralf,

Manche meiner Protokolle wurden über 10 und mehr Jahre verwendet und weiter entwickelt.
Dabei haben sich folgende Punkte bewährt:
1. Prüfsumme
2. Einen Befehl, womit man abfragen kann, welche Protokoll-Version das Gerät implementiert hat. Dieser Befehl darf dann nie mehr verändert werden. besonders wenn man einen PC als Master hat, spielen Codegrösse und Rechengeschwindigkeit keine grosse Rolle und man kann dann neuere Befehle mit alten emulieren, falls nötig.
3. Nicht verstandene Befehle werden ignoriert. Der Sender kann dann verlorene Antworten über einen Timeout erkennen, falls nötig und ein Empfänger hängt sich nicht auf, wenn er auf Befehle stösst, welche erst später definiert wurden.
4. Einen Befehl zum Abfragen des Modultyps.
5. Praktisch ist auch die Möglichkeit direkt auf Interna des Moduls zugreifen zu können, wie z.B. direktes Abfragen von Eingängen und setzen von Ausgängen. Ist bei der Installation und Fehlersuche unheimlich hilfreich

Das sind so meine 40 Jahre Erfahrung mit Protokollen. Bei mir kann noch hinzu, dass das Ganze an Kunden ausgeliefert wurde und es nicht nur ein einzelnes System war über welches man die Übersicht hat.
Ich musste auch Berücksichtigen, dass einem Kunden ein Gerät der neuesten Generation als Ersatzteil oder Erweiterung ausgeliefert wurde und seine Anlage sollte auch dann weiterhin funktionieren.
Teilweise hat dann die Software auch eine Meldung ausgegeben, dass sich der Kunde um ein Update kümmern soll, wenn neuere Komponenten eingefügt wurden. Das war noch zu Zeiten ohne Internet.
Auch meine Datenbanken waren entsprechend aufgebaut, da war im ersten Record immer eine Versions-Nummer drin. Meine Programme konnten dann immer das alte Format in das neue konvertieren, sodass man nicht alles wieder neu eintippen musste.
Zumindest in C funktioniert dies auch mit Konfigurationsdaten, wenn man weiss wie diese im Speicher verwaltet werden und wie man den Linker steuern muss. Dabei ist es aber auch wichtig, dass unbenutzte Bit einen definierten Zustand besitzen.

MfG Peter(TOO)

[Feuerring]

Update ...

habe mal angefangen mit dem FUNK-Modul,

das Timing für die von mir verwendeten ELRO-Funksteckdosen erzeuge ich im NANO und kann per Befehl gesteuert werden.
Die Bit-Sequenz 128-Takte werden 10 mal wiederholt ...

----------------- Modul spezifisch Kommandos -----------------

E0 = Modul spezifisch                                                         #zzaaE0|F1|F2|F3|F4|Fx*

----------------- FUNK - Modul  -----------------
#zzaaE0|F001|01|123456789ABC*
 
F1 = F001 (433MHz-Funk an PB.1 ... Sende-LED an PB.0 )
F2 = Funktion 01 ... senden 
F3 = ELRO-Daten   12 Byte ...   0 = 0 / 1 = 1 / F = foat 
 
              #zzaaE0|F001|01|0F0FF0FFFFF0*                            Sys-Code [ 0F0FF ]  Taste-Code [ 0FFFFF ]  [ 0 ]   = AUS
              #zzaaE0|F001|01|0F0FF0FFFFF1*                            Sys-Code [ 0F0FF ]  Taste-Code [ 0FFFFF ]  [ 1 ]   = EIN
              #zzaaF1E0*... Antwort

[Feuerring]

Update ...

es geht weiter ...

um mit den Modulen besser arbeiten zu können habe ich mein PC-Programm erweitert,
so kann jedes Modul entsprechend über die Gruppen-Register leicht programmiert werden.




Das Aussen-Sensor-Modul ist soweit bereits fertig, MCU muss nur noch in ein Gehäuse.

Es wird die Helligkeit in zwei Spektral-Farben (640nm und 940nm) sowie Luftdruck und Temperatur gemessen und bereit gestellt.

Das Relais(Aktor)-Modul ist auch fertig


Das Funk-Modul ist noch in der Testphase aber auch fertig (obere Schaltung)

Die untere Schaltung ist das Steuer-Modul für die Lüftungsanlage
noch im Aufbau, bereits integriert 1Wire-Temp Sensoren

[Peter(TOO)]

Hallo Ralf,

Ich würde beim Protokoll noch eine Prüfsumme und die Länge einfügen!

Du musst immer mit Übertragungsfehlern rechnen. Der Empfänger kann dann fehlerhafte Datensätze einfach wegwerfen. Antworten macht keinen Sinn, da auch das Sender-Feld gestört sein kann.
Dem Sender könnte man dann einen Timeout spendieren. Wenn die Antwort nicht innerhalb des Zeitfensters kommt, gilt sie als verloren gegangen.

Wenn bei einem Gewittersturm das Licht etwas verzögert reagiert ist das nicht tragisch. Wenn stattdessen aber die Markise ausfährt ...

MfG Peter(TOO)

[Feuerring]

Hallo zusammen,

mein PC zeichnet alles auf was auf dem BUS los ist, unter anderem auch die Status-Meldungen.

hier mal eine Auswertung der Daten vom Außen-Sensor:



Noch läuft die Schaltung (BUS-System) aus meinem Schreibtisch

[Feuerring]

Hallo Peter

Ich würde beim Protokoll noch eine Prüfsumme und die Länge einfügen!

hatte ich auch schon drüber nachgedacht, der Datensatz hat ein definierten Anfang (#) und ein definiertes Ende chr(13),
also benötige ich keine Längen Angabe ... Länge ich auf 100 Zeichen begrenzt ...
im Empfänger wird als erstes der Header geprüft, erst dann werden die Felder auf Plausibilität geprüft ...

Gut eine Prüfsumme könnte ich hinten anhängen #zzaakk|F1|F2|Fx%PS* (*)=chr13)

Als Prüfsumme alle Byte bis % aufaddieren und bei 255 Überlauf ... so habe ich immer als PS ein Byte ... sollte doch reichen ?!

[Peter(TOO)]

Hallo Ralf,

hatte ich auch schon drüber nachgedacht, der Datensatz hat ein definierten Anfang (#) und ein definiertes Ende chr(13),
also benötige ich keine Längen Angabe ... Länge ich auf 100 Zeichen begrenzt ...

Nunja, was ist mit den Antworten mit Text?
Das Start- und Ende-Zeichen kann auch gestört sein.
Eine logische Erweiterung für die Zukunft ist sicher die Möglichkeit die Firmware upzudaten.
Dann könnte es auch Module mit einem LCD geben. Ist immer praktisch wenn man da auch einen Text direkt rein schreiben kann.

Die Länge, möglichst als erstes Byte erspart dir eine Menge Ärger und Aufwand.
- Jetzt weisst du die Länge erst wenn du das Kommando dekodiert hast. Hast du ein älteres Modul, welches ein neues Kommando nicht kennt, hat es keine Ahnung wie lange die Meldung ist.
- Mit einer Länge darf ein "#" in einem Text enthalten sein.
- Mit der Länge am Anfang kann man eine Schlaufenzähler setzen und entsprechend viele Zeichen einlesen. Ist die Länge grösser als der Puffer, ignoriert man einfach alles bis zum nächsten chr(13)
- Ist der Zähler durch, MUSS das nächste Zeichen ein chr(13) sein, andernfalls ist die Meldung fehlerhaft.

Als Prüfsumme alle Byte bis % aufaddieren und bei 255 Überlauf ... so habe ich immer als PS ein Byte ... sollte doch reichen ?!

Man sollte (Prüfsumme-1) übertragen. Falls eine Meldung mit lauter 0 übertragen wird, ist sonst die Prüfsumme auch 0. Bei einem Programmfehler (Absturz) kann das Restprogramm dauernd ein konstantes Byte senden. Ist dies 0 wertet die Prüfsummen-Prüfung dies als gültige Meldung. Hier hilft auch die Länge im Protokoll


Ich habe in meinem Leben eine Menge proprietäre Protokolle im Industriebereich entwickelt und eine Menge Treiber für bestehende Protokolle implementiert. Eine Prüfsumme ist unverzichtbar.
Eine Längenangabe hilft ungemein, wenn es um spätere Erweiterungen geht

Bei meinem Protokollen gab es, dank der Länge, immer auch Mechanismen um Daten direkt durch ein Gerät hindurch zu einem anderen Endpunkt zu schleifen. Damit konnte ich auf Geräten Interpreter für den Abgleich oder Service direkt ansprechen ohne an den dazwischen liegenden Geräten die Software anpassen zu müssen. Es gab einzig den Befehl "Daten weiterreichen" in allen Geräten.

Mit Start-Zeichen, Länge, Prüfsumme und End-Zeichen kann man einen sehr robusten Header bauen, welcher auch bei Störungen immer wieder auf die Füsse fällt ohne kompliziert zu werden. Zumindest die Header-Auswertung habe ich fast immer direkt im Empfänger-Interrupt gemacht. Meistens mit einer Statemachine. Mit dem letzten empfangenen Zeichen ist der eigentliche Inhalt schon dekodiert und geprüft. Fehlerhafte Meldungen werden einfach weggeworfen.


MfG Peter(TOO)