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

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