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]

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

32286 32287




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


32353 32354

Das Aussen-Sensor-Modul ist soweit bereits fertig, MCU muss nur noch in ein Gehäuse.
32355
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
32356

Das Funk-Modul ist noch in der Testphase aber auch fertig (obere Schaltung)
32357
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 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)

[Feuerring]

Hallo Peter,

erst mal besten Dank für deine Antwort


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.

Ich lese die com in der MCU per Interrupt mit inkey aus und hänge jedes eingelesene Byte an ein String an bis ein chr(13) eintrifft,
erst dann wird die Zeichenfolge übergeben und ausgewertet (Startzeichen) länge statischer Header, Plausibilität und Anzahl der Felder .

Treffen mehr als 100 Zeichen ohne chr(13) ein, wird der String verworfen ... der Tipp mit der Prüfsumme (-1) ist gut,
wobei ich nur Ascii übertrage, sendet ein Modul permanent Zeichen ist eh der BUS gestört, da hilft nur abschalten ...
Mein Home-Server läuft immer, der wird die Aktivitäten auf den BUS mit sniffen und in eine LOG schreiben,
Derzeit baue ich den BUS erst mal auf meinem Schreibtisch auf und teste alles, bevor ein Modul an seine Stelle kommt.

Ich betreibe an dem BUS keine Geräte die kontrolliert betrieben werden müssen, nur Außenbeleuchtung und Event-Beleuchtungen und Sensoren,
die Steuerung der Lüftungs-Anlage ist autonom und soll nur über den BUS im zugelassenem Bereich beeinflusst werden können.

Das Updaten der FW über den BUS werde ich nicht vorsehen, denke darauf kann man gut verzichten ...

[Peter(TOO)]

Hallo Ralf,
Die "dummen" Ideen kommen oft erst mit dem schlechten Wetter.

Es muss gar nicht etwas kompliziertes werden.
Wie wäre ein Klingelknopf mit LCD. Normal wird der Name angezeigt und wenn man klingelt steht da z.B. "Bin im Garten" oder sonst ein kurzer Text.
Braucht einen µC, Taster, kleines LCD und evtl. ein Relais um die normale Klingel anzusteuern.

Ich hatte früher in meinem Büro eine kleine Steuerung mit 8 Kanälen, da waren das Licht und Steckdosen dran angeschlossen. Konnte mit Tasten und über den PC gesteuert werden, war aber autonom. Neben der Tür gab es noch eine roten Taster. Beim Rausgehen konnte man damit alles ausschalten und beim Reinkommen wurde die Grundbeleuchtung und einige Steckdosen eingeschaltet. Neben dem roten Taster waren noch 8 weitere. Beim WC gab es nur einen Taster für das dortige Licht. Über den PC konnte man auch alles steuern, die Gruppen für den roten Taster konfigurieren und auch die Software updaten.

MfG Peter(TOO)

[Feuerring]

Hallo Peter,

habe mir noch mal Gedanken gemacht,

die Checksumme werde ich als Option verwenden,
diese kann mit übertragen werden muss aber nicht,
wird eine Nachricht mit CS übertragen muss diese natürlich auch stimmen ...

Beispiel :

#zzaakk|F1|F2|F3|....|Fx [13] .... ohne CS wie gehabt

#zzaakk|F1|F2|F3|....|Fx [30] CS [13] .... mit CS = (HEX)

als Trennzeichen habe ich mich für chr(30) "Record Separator" entschieden.

Die Checksumme könnte durch aufaddieren der Bytes bebildet werden, mit Überlauf bei 255 ... Bascom cs = checksum(string)
zusätzlich addiert man noch die Anzahl der Übertragenen Bytes auf ...

Bedeute aber das nicht alle Fehler erkannt werden ...

Beispiel
"#325501|01|01|02|02|" CS = 69 +20
"#325501|00|00|04|02|" CS = 69 +20

mann müsste eigentlich noch ein zweites Verfahren anwenden z.B. XOR

oder gleich Bascom cs = csc8(string) verwenden, beinhaltet bereits alles ...

in VB würde das dann so aussehen:


Function Docrc8(s As String) As ByteDim j As Byte
Dim k As Byte
Dim crc8 As Byte
crc8 = 0
For m = 1 To Len(s)
x = Asc(Mid(s, m, 1))
For k = 0 To 7
j = 1 And (x Xor crc8)
crc8 = Fix(crc8 / 2) And &HFF
x = Fix(x / 2) And &HFF
If j <> 0 Then
crc8 = crc8 Xor &H8C
End If
Next k
Next
Docrc8 = crc8
End Function


Bascom cs = csc8(string)

Beispiel
"#325501|01|01|02|02|" CS = 238
"#325501|00|00|04|02|" CS = 228

[Peter(TOO)]

Hallo Ralf,

Aus meiner Erfahrung im Industriebereich reicht Summe-1 völlig aus!
Fehlverhalten, durch gestörte, nicht als fehlerhaft erkannte Datentelegramme wurden nie beobachtet. Dies hätte dann auch in den gespeicherten Messwerten als Ausreisser auftauchen müssen.
Was öfters vor kam war, dass die Verbindung z.B. durch direkt parallel zur Datenleitung verlegte Kabel zur Versorgung grosser Motoren durch Umrichter, zu sehr gestört wurde. bei einem10kW-Motor halfen auch die geschirmten Datenleitungen und RS-485 nichts. Aber mit 10-20cm Abstand in der Kabeltrasse war es dann kein Problem.

Auch CRC erkennt nicht alle Fehler zu wirklich 100%, braucht aber wesentlich mehr Rechenaufwand.
So eine 8-Bit CRC braucht in etwa 4 Schiebebefehle und 4 Additionen und zusätzlich noch Befehle für die Schleife usw.

MfG Peter(TOO)

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

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:

32377

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