Hallo!
Ich hab meine Fritzbox mit dem CUL433 Stick im Betrieb und in FHEM sind bereits diverse Steckdosen/Schalter/Lampen/Geräte von Intertechno erkannt, benannt, mit Timern versehen, etc. Klappt auch alles wunderbar. Leider klappt es mit den Außensensoren noch nicht so.
Im Zuge dessen hab ich mal ein paar Attiny's programmiert mit billigen 433Mhz Chips und kann damit auch Intertechno-Funksteckdosen schalten (Ich sende eine 10010101 Folge im IT-Protokoll). Das klappt also.
Jetzt möchte ich aber auch gerne Temperaturwerte, Messwerte, Reed-Kontakte etc. mit nem Attiny und nem 433MHz Chip versehen und die Daten über den CUL-Stick ins FHEM laden/schicken. Die Temperatur soll dann z.B. als Plot dargestellt werden - die Reed-Kontakte als offen/zu, und was anderes vielleicht nur als einzelne Zahl.
Wie kann ich das machen?
Mein erster Ansatz war, nach bestehenden Protokollen zu schauen und diese zu "simulieren", da die Geräte ja vom FHEM erkannt werden. Das ist aber viel zu kompliziert und ineffizient.
Mit welchem Protokoll kann ich denn dem CUL-Stick Daten senden, die ich dann auswerten und darstellen kann?
Also Pulslänge, Bitdarstellungen. Dass ich z.B. ein eigenen Sensor vorne mit der Signatur 1234 versehe und dann die Daten:
Temperatur-Beispiel: 1234 0122 sind dann 12,2 Grad (natürlich in Binärdarstellung gesendet).
1. Fhem muss das bekommen
2. Ich muss empfangene Daten mit meiner ID aussortieren und auswerten
3. Die Daten müssen im Web-Interface dargestellt werden
Vielen Dank für Hilfe!
Wenn Du je auf ''Eigenbau' setzen willst... Einfacher wird es sein, wenn Du auf ein bereits bestehende, fertige und gut unterstützte System setzt.
MySensors wäre so ein Fall. Günstig ist es auch noch dazu. Geht aber nicht mit CUL, hat eigenen Gateway (Kostenpunkt < 10 Euro).
s www.mysensors.org + Forum-Suche.
Ich möchte ja schon bei dem CUL-Stick mit FHEM bleiben - auch der stromsparende Betrieb an der FritzBox ist elegant.
Neue Sensoren werden ja auch eingebunden per PM Modul.
Dann muss die Verarbeitung ja irgendwie gehen.
Z.B. Hat bjoernh seinen Temperatursender analysiert und ein PM Modul geschrieben und die Werte werden angezeigt.
Stromsparen ist eher kein Argument, der MS-Gateway verbraucht nicht mehr als CUL, also wenig.
Man kann natürlich auch komplet alles selbst machen. Ist halt die Frage des Aufwandes. Ich sehe jedoch die Vorteile nicht.
Evtl. wäre FS20 Protokol was für Dich, da gebe es bereits fertige Module (auch wenn FS20 jetzt schon ein totes Pferd ist).
HomeMatic wäre zwar mit dem CUL auch möglich, aber nicht gleichzeitig mit SlowRF.
Mit den 1€-Chips ohne Eigenintellegenz (wenn Du das hast, was ich meine), würde ich nicht machen - langsam, störanfällig, schlechte Reichweite.
Es geht mir ja nicht um das System als ganzes, sondern um die einzelnen Punkte, die mir nicht klar sind:
z.B.
1. Ein Aussenthermometer sendet fröhlich zum Cul-Stick a la "Cul Parse: s00CCabcde123"
Auf dem Papier weiß ich welche Bits wohin gehören. Die HEX Zahlen in Binär bzw in echte Temperatur/Luftfeuchtgikeit umzurechnen ist programmiertechnisch leicht. Aber WIE und WO mache ich das? Programmiersprache PERL, OK.
Aber ich verstehe nicht WIE ich an die empfangenen Daten komme, die im Log-File von FHEM unter verbose 4 sichtbar sind.
Und WIE ich die errechneten Temperaturen weitergeben ans WEB Interface, dass ich sie plotten kann. Nehm ich da ne xyz.pm Datei und schreib da den Code rein? Oder geht das auch in meiner 99_myutils.pm?
Gibts da ein Tutorial zu? Wie ich empfangene Daten abgreifen kann?
2. Das andere ist das Funkprotokoll-Problem: Ich programmiere meinen Sender auf ne IT Steckdose - die wird dann zuverlässig geschaltet und FHEM bekommt das mit und zeigt mir den Status -> super.
Manche Temperatursender senden die oben genannten s00CC... Codes an FHEM. Andere wiederum gar nicht.
Das liegt doch (da die Frequenz fest ist bei 433,92MHz) nur an den Pulslängen/Bitdefinititonen. Also eben dem Protokoll.
Welche Protokolle kann ich mit dem Cul-Stick FHEM denn grundsätzlich empfangen? Es gehen ja nicht nur die Bekannten, sondern auch die Unbekannten, siehe oben. Es muss also z.B. sowas sein wie: Alle Signale mit Pulslängen von 100-1000 us und mit folgenden Bit-Definitionen: 3x high, 2x low, etc.
Nachtrag: Die Reichweite meiner 2 Euro Module ist sehr gut. Sender (3-12V) wird bei 5V betrieben und sendet mit angelöteter Antenne 15m durch Decken/Wände. Laut Datenblatt sind es bei 12V 200m im freien Feld - das glaube ich auch. Wenn sie mit den knapp 4V eines 18650 Akkus funken, wird das locker reichen. Den Empfänger hab ich bislang nur im Meter-Bereich ohne extra Antenne getestet - gabs auch keine Probleme. http://www.amazon.de/gp/product/B00ATZV5EQ?psc=1&redirect=true&ref_=oh_aui_detailpage_o04_s00 Diese Module sind das. Sehr zu empfehlen.
Kenne die Module, habe hier rum liegen. Kein Vergleich zum Prozessorgesteuerten Dingern wie CC1101 (steckt auch im CUL), nRF24L01+ oder FRM69.
Du musst erstmal sehr viel Lesen und in die anderen Module reinschauen.
http://www.fhemwiki.de/wiki/DevelopmentModuleIntro
http://www.fhemwiki.de/wiki/DevelopmentGuidelines
Ich habe mal so etwas gebastelt (meine Sensoren hatten RFM12B), aber dann doch fallen gelassen, da fertige Systeme, die gepflegt und weiterentwickelt werden, einfach immer besser sein werden. Vlt. nutzt Dir dennoch als Vorlage: https://github.com/hexenmeister/MyFHEM/blob/master/FHEM/36_GSD.pm Als Gateway habe ich JeeLink-Modul genommen (entsprechend hatte ich einen JeeLink-Stick mit einer leicht modifizierten Version von Demo-Firmware verwendet). JeeLink und CUL Module können also für Dich von Interesse sein.
Viel Erfolg :)
Oh, das sieht ja schonmal gut aus - da gibts viel dazu zu lesen. Muss ich mir mal vornehmen.
Ich hab auch noch etwas weiter gesucht bezüglich der Protokolle und unter http://culfw.de/commandref.html gibts ne gute Übersicht.
Allerdings bin ich noch verwirrt, welche Protokolle für 433Mhz genutzt werden.
Keine Ahnung, spielt aber auch keine Rolle, wenn Du selbst alles machst. Alledings wird mit Deinen Funk-Modules vermutlich nicht viel mehr möglich sein, als InterTechno.
Okay, ich hatte jetzt mal ein bisschen Zeit um mich etwas einzulesen.
Habe aber noch grundlegende Verständnisfragen :)
Mir gehts erstmal um den grundsätzlichen Empfang in FHEM.
Ich hab meinen Sender jetzt so konfiguriert, dass ich im IT-Protokoll senden kann. D.h. ich sende 24 Bits "0101..." und im Log steht dann sowas wie: CUL_Parse: CUL_0 i5555AA01 -73.5
Wenn ich weniger oder mehr Bits schicke, scheint in FHEM nichts anzukommen.
Dann hab ich mal in die 00_CUL Datei geguckt, da ist definiert:
"G:IT" => "^i......",
Stehen die Punkte für einzelne Bytes?
Hab ich dann einfach weiter unten noch eingefügt:
"L:SM" => "^x............",
SM steht für SelfMade und 12 Punkte, weil ich 12 Bytes a 4 Bits schicke -> 48 Bits anstatt 24 wie bei IT.
Manche Definitionen haben ein "\$" am Ende?!
Dann steht noh weiter unten:
} elsif($fn eq "i" && $len >= 7) { # IT
$dmsg = lc($dmsg);
Verstehe ich so: Wenn der Prefix "i" ist, also IT UND die Nachricht länger als 6 Zeichen, dann mache was.
Hab ich weiter unten wieder eingefügt:
} elsif($fn eq "x" && $len >= 11) { # SelfMade SM
$dmsg = lc($dmsg);
Also soll das gleiche passieren, wenn ein x vorne ist und die Nachricht mindestens 10 Bytes lang ist.
Und bei den my $clientsSlowRF = ":FS20:FHT.*:KS300:USF1000:BS:HMS: ".
":CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: ".
":ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: ".
":STACKABLE_CC:CUL_RFR:SM:CUL_TCM97001:";
hab ich mein SM auch eingefügt.
Wenn ich jetzt 48 Bits sende, passiert NICHTS :)
Ok, gibt ja noch z.B. das IT_10 Modul für den IT Empfang. Woher kommen eigentlich die zweistelligen Zahlen am Anfang? Willkürlich? die 99 wird wohl als erstes geladen?!
Da ich noch kein Cul_Parse sehe bei meinen 48 Bits, brauche ich wohl auch noch ein Modul?
Aber im Modul steht die Funktion ja eigentlich als Modulname_Parse, also muss das ja doch in 00_Cul passieren?
Ok, nehme ich z.b. Das TCM Modul von Björn und kopiere das und bearbeite das.
Muss das speziell genannt werden? Wird das automatisch geladen? Hab dem jetzt den Namen 14_SM gewählt.
Vielen Dank für die Hilfe
Zitat von: meggih am 07 Oktober 2015, 14:26:57
Dann hab ich mal in die 00_CUL Datei geguckt, da ist definiert:
"G:IT" => "^i......",
Stehen die Punkte für einzelne Bytes?
Hab ich dann einfach weiter unten noch eingefügt:
"L:SM" => "^x............",
SM steht für SelfMade und 12 Punkte, weil ich 12 Bytes a 4 Bits schicke -> 48 Bits anstatt 24 wie bei IT.
Manche Definitionen haben ein "\$" am Ende?!
Da ich mich im CUL-Modul nicht auskenne, kann ich dazu leider auch nicht viel sagen.
Ansonsten sieht es nach einer RegEx zum Erkennen von Gültigen nachrichten. ^ steht für Anfang der Zeile, ein Punkt für ein beliebiges Zeichen. Bytes sind das dann eher nicht, sondern müssen scheinbar Symbole sein. $ steht eigentlich für das Zeilenende, hier ist dieser jedoch maskiert...
Zitat
Ok, gibt ja noch z.B. das IT_10 Modul für den IT Empfang. Woher kommen eigentlich die zweistelligen Zahlen am Anfang? Willkürlich? die 99 wird wohl als erstes geladen?!
99 wird immer galden. Andere Zahle nur, fall ein entsprechendes Modul definiert ist (define mysm SM ...). Die Zahl bestimmt auch die Lade-Reihenfolge.
Zitat
Da ich noch kein Cul_Parse sehe bei meinen 48 Bits, brauche ich wohl auch noch ein Modul?
Aber im Modul steht die Funktion ja eigentlich als Modulname_Parse, also muss das ja doch in 00_Cul passieren?
Ok, nehme ich z.b. Das TCM Modul von Björn und kopiere das und bearbeite das.
Muss das speziell genannt werden? Wird das automatisch geladen? Hab dem jetzt den Namen 14_SM gewählt.
Du brauchst in der Tat ein eigenes Modul, CUL im Alleingang zu verändern ist keine so gute Idee, bei jedem Update sind die Anpassungen weg.
14_SM ist OK. 00_SM wäre auch ok...
Hab grade noch ein paar Tests gemacht und bin jetzt wieder verwirrt.
Die Änderungen in der CUL_00.pm-Datei scheinen ihn gar nicht zu interessieren.
Hab den IT-Prefix mal von i auf x gemacht und im Log steht immer noch i.
Trotz shutdown restart und reload Cul_00.
Hmm...
Zum CUL-Modul bin ich leider überfragt :(
Am besten in SlowRF-Board fragen oder den Entwickler (rudolfkoenig) direkt anschreiben.
Ja, muss ich mich nochmal anderweitig umhören - ob sich da jemand auskennt.
Ich hab mir auch die geposteten Links alle durchgelesen und z.B. gesehen:
ZitatX_Read
Die X_Read-Funktion wird aus der Hauptschleife von FHEM aus aufgerufen wenn das Gerät, für das das Modul zuständig ist, Daten bereit gestellt hat, die gelesen werden können.
Mein erstes Ziel war ja, dass die Cul-Parse Funktion im Log mal meine Daten anzeigt, die ich geschickt habe.
Aber dann muss ich erst das Modul soweit ändern, dass es im Read direkt ne Log3 Ausgabe erzeugt. Dann sehe ich ja, ob das Modul überhaupt aufgerufen wird.
Wobei ich mich immer noch Frage, WIE und WO genau entschieden wird, welche Daten für welches Modul geeignet sind.
Da sind diverse Platzhalter drin wie "^K........." und daneben dann "^M......", die sich nur durch ihre Anzahl der Punkte unterscheiden. Wenn also die Länge abgefragt wird, ist das das einzige, auf das ich achten muss.
Also könnte ich ein bestehendes Format nehmen, wie TCM97001 oder IT und nur die Länge länger machen und im richtigen Moment die Daten umleiten zu meinem Modul :) Das wäre toll.
Das Modul mach irgendwo DevIo_OpenDev und öffnet das Gerät, was beim Define angegeben wurde.
im CUL_Read wird DevIo_SimpleRead aufgerufen.
Bekanntgemacht sind die Methoden hier:
$hash->{ReadFn} = "CUL_Read";
$hash->{WriteFn} = "CUL_Write";
$hash->{ReadyFn} = "CUL_Ready";
Aber für die Details bin ich überfragt.
Hallo !
bin jetzt auf diesen Thread gestossen.
Gibt es hier schon neue Erkenntnisse ? Das gleiche Vorhaben habe ich auch. Möchte mit kleinen Funksendern am AVR Tiny Werte an Fehm senden, finde nur kein passendes Protokoll. IT funktioniert, senden und Empfangen, möchte aber mehrere Daten Übertragen
(z.B. Helligkeitswert, Batteriestatus etc.). Habe am RasPi2 einen NanoCUL mit a-culfw. (433MHz)
Habe bis jetzt versucht mehrere Protokolle nach zu stellen (z.B. TCM) komme aber nur bis zu einem Log-Eintrag "unknown message ..."
Hier weiß ich dann nicht wie weiter.
Gruss Mirko
Hallo,
ja, ich hab jetzt fast alles "am Laufen".
Schalter/Kontake/Relais/Digitale Übertragungen mache ich mit dem IT-Protokoll,
Analoge Temp/Hum/Batterie-Werte mache ich mit einem TCM-Protokoll.
Kleine Sender entweder mit nem RECOM 5V Teil an 230V oder mit ner einzelnen 18650-Zelle irgendwo im Garten oder sonstwo :)
Attiny85, FS1000A-Sender, RXB12-Empfänger, Kleinkrams.
Jetzt bastel ich gerade noch einen selektiven Repeater für weiter im Garten entfernte Bewegungsmelder/Garagenkontakte (auch selbst gebaut).
Hallo,
danke für die Antwort.
So weit bin ich jetzt auch schon. Habe selbstgebaute Schaltaktoren, welche IT-Protokoll empfangen und per IT-Protokoll den Zustand zurückmelden. Habe auch Sensoren (Helligkeit, Temp, Luftfeuchtigkeit) welche per TCM97000 Protokoll mit eigener Kennung an FHEM senden. Zur Zeit muss ich jedoch immer in der TCM97000.pm eigenen code zur Auswertung unterbringen, d.h. nach einem Update ist das immer wieder weg. Würde gern alles in ein eigenes Protokoll packen, aber da komm ich nicht weiter.
Wie wertest Du deine Sensoren aus ?
Ich schicke die Daten alle als Temp/Hum codiert zum FHEM und rechne sie dann um und benutze sie: z.B. Jeder Temp-Sensor hat z.B. ID 100 mit T/H und also ID 101 kommt dann 5,52V Batterie als 55,2C an.
Also mit T/10 hat man dann die Batteriespannung.
Ich hab mir kleine Platinen geätzt und teilweise "alte" Bewegungsmelder geupdated, so dass FHEM alles mitbekommt. Und falls ne Lampe da ist, die angesteuert werden kann.
Ansonsten ist die Auswertung der IT-Dinger ja normal, wie bei den Steckdosen/etc auch. Manchmal n notify abhängig von sunrise/sunset, wenn die Batterie unter 3,5V fällt gibts ne Warnung und sowas..
Was noch nicht passt sind manchmal seltsame Funk-Verhalten, Signale kommen manchmal nicht an - bin aber schon vielen Fehlern auf die Schliche gekommen mit nem Arduino zum Testen und nem Oszilloskop.
Und hab erfolglos versucht, dass Telegram Modul, meinetwegen auch n Whatsapp Modul einzurichten, dass ich z.B. auf Garage Auf-Zu Nachrichten ans Handy bekomme..
Na dann sind wir wohl beide so etwa auf dem gleichen Stand. Mit der Benachrichtigung aufs Handy geht recht einfach per Mail. Hab zB einen kleinen Sender an der Klingel. Klingelts draußen-> Bild von Cam auf Sat Receiver, Bild per Mail an mich und alle Telefone klingeln 4 mal.