Hallo,
durch Zufall bin ich auf die Seite von MySensors.org (http://mysensors.org) gestoßen, welche ich sehr Interessant finde.
Zumal die Kosten für die Clients und des Gateway sich sehr im Rahmen halten (eigentlich sehr sehr günstig sind).
Man nehme 1x Arduino Pro Mini, 1x NRF24L01+, + den Sensor deiner Wahl, fertig ist der Client :-)
Alle Libaries und Beispielcodes sind OpenSource. Einige Hausautomations-Systeme werden schon unterstützt, nur halt leider nicht FHEM (welches aber erwähnt ist :-) ).
Jetzt zu meiner Frage:
Ist es evtl. in naher Zukunft von den FHEM Programmieren geplant, eine Intergration/Unterstützung von MySensors auf den FHEM-Server durchzuführen?
Ich habe einige Clients testweise stabil am laufen. Nur wäre es für mich und evtl. auch anderen Interressant zu Wissen, ob eine Implementierung hier geplant ist, damit man (ich) nicht in die falsche Richtung seine Schaltung/HAA entwirft.
Danke
Prinzipiell gibt es das schon alles.
Der Punkt ist der:
Zum einen muss man den Arduino mit fhem zusammen bringen. Hierzu gibt es z.B. Ethersex (Arduino mit LAN), oder schau dir die PanStamps an. Quasi mini Arduinos mit 868MHz Funkmodul integriert.
Dafür existieren in fhem schon Module.
Sketche für die Sensoren gibt es im Internet zuhauf.
Das Problem ist, dass jeder seine Sensoren an irgendwelche Pins klemmt, und jeder andere Sensoren will.
Daher findest du so direkt wenig. Im Bastelforum ist ein Thread der z.B. versucht, Innenraumsensoren auf PanStamp Basis zu verwirklichen. Lies mal rein.
Was imho ein Problem, bzw eine "Marktlücke" darstellt:
Ein HowTo, wie man aus einem 0815 Sketch für einen Arduino einen Sketch macht, so das man Ethersex oder PanStamps Swap Protokoll in fhem nutzen kann.
Das fehlt quasi noch...
Hallo Rince,
Ethernet ist ein gutes Stichwort.
Ich habe mir den neuesten Sketch von mySensors.org mal nachgebaut:
http://mysensors.org/build/ethernet_gateway
Das wäre schon mal ein Ansatz.
Ich habe mal versucht per HTTPMOD was ins fhem zu bekommen.
2014.09.06 23:14:33 4: HTTPMOD: GetUpdate called, hash = HASH(0x1326038), name = mysensors
2014.09.06 23:14:33 4: HttpUtils url=192.168.178.66:5003
2014.09.06 23:14:33 3: HTTPMOD got error in callback: 192.168.178.66:5003: malformed or unsupported URL
Das Gateway liefert mir derzeitig ja nur die Werte (Kanal, Wert usw..) auf das Webinterface.
Verstehe ich das richtig.. wenn ich den Sketch anpassen würde, wie auch immer, könnte man von den MySensors-Sensoren die Werte direkt in den Readings schreiben?
Übrigens fände ich es cool, wenn fhem auch neben Ago Control, OpenHAB, PiDome, Vera und Indigo Domotics auch in der Liste auftauchen könnte.
robin
Hi,
also ich habe mir den USB/seriell Gateway nachgebaut und habe ihn momentan zum Testlauf am PC angeschlossen und steuere die Clients über ein Terminalprogramm.
Ich dachte, das es ja so ähnlich funktionieren müsste wie ein "Cul", werden die Daten dort nicht auch seriell über den USB zum FHEM übergeben?
Somit bräuchte man den Gateway (USB-Version) nur an den Raspberry anzustecken (wie ein CUL).
Wenn ich jetzt total FALSCH liege, dann klärt mich bitte auf :-)
Danke
P.S.: Ob nun die USB (serielle) oder die Netzwerk-Version von FHEM unterstützt wird, wäre mir eigentlich egal, getestet habe ich bisher nur die USB/serielle Version. Sobald mein Ethernet Modul bei mir eintrifft (in ca. 14 Tagen) werde ich auch diese Version mal testen :-) Da ist man bei MySensors halt sehr flexibel :-)
Schon recht, man müsste so ein CUL-ähnliches Modul für die Input-Gateway (also Transmitter) erstellen, und dann Module für jeden Sensor-Typ.
Was mir an diesen Projekt nicht gefällt, ist der verwendete Transmitter. Bei 2,4GHz kommt man einerseits mit dem WLAN ins Gehege, andererseits ist die Reichweite nicht wirklich gut. Nicht umsonst senden meiste Sensoren auf den anderen Ferequenzen (in DE 433MHz oder 868MHz).
Daher habe ich mich bei meinen Selbstbau-Sensoren für ein anderes System entschieden (http://s6z.de/cms/index.php/homeautomation/eigenbau/56-tinytx-wireless-sensor-nodes). Als Empfänger kann JeeLink verwendet werden. Da gibt es auch schon ein FHEM-Modul dafür. Ein FHEM-Modul für DHT22-Sensor habe ich dann selbst geschrieben. Kann evtl. als Vorlage dienen...
Hallo Hexenmeister,
da muss ich die widersprechen. Ich habe das mit meinem WLAN getestet, Fritzbox und Apple Time Capsule und habe keine Störungen gehabt. Von der Reichweite kann ich dir sagen, das das Signal locker durch zwei Räume ging. Am "Gateway" habe ich eine Versiono mit längerer Antenne genommen (kostete 4 Euro).
LG
/Robin
Widersprechen?! Das geht nicht! ;)
Aber Spaß beiseite, dass das mit WLAN parallel geht ist klar (Stichwort Collision Detection), die Frage ist, ob der Durchsatz dabei merklich leidet oder nicht. Und die Reichweite mag zwar in einem Fall ausreichend sein, aber die 2,4GHz -Wellen werden nun mal stärker adsorbiert als 868MHz. Bei mir kommt WLAN durch die (Eisenbeton-)Decke fast gar nicht durch, die HomeMatic-Kommunikation (868) erfolgt jedoch problemlos.
Ansonsten hat das System natrürlich seine Daseinsberechtigung. Und eine FHEM-Integration wäre sicherlich nicht verkahrt. Wenn jemand das machen will, kann sich CUL oder Jeelink Module ansehen.
Hi Hexenmeister,
jetzt laufen wir wieder kongruent :-)
Sehe ich genauso. Die Technik davon ist preiswert und wenn sich jemand hinsetzt und ein Gateway für Fhem schreibt, ist es wieder eine Bereicherung für dieses offene System. Ich würde es auch begrüßen (wie fh555), denn ich habe auch - mehr aus Spaß - mit einigen Sensoren rumgespielt. Ob die sich für den Alltag eignen (Stabilität, Laufzeit etc.) wird sich zeigen, wenn die an Fhem angeflanscht sind.
Viele Grüße
Robin
Ah, nee, wenn sie schon richtig "angeflanscht" sind, ist es schon zu spät ;)
Ich würde erstmal eine provisorische Anbindung an FHEM erstellen und dann sehen, ob's gut läuft.
Also zunächst ein einfacheres Prototyp-Modul, wo hard verdrahtet und stumpf ein bestimmter Sensor abgefragt wird.
Ich habe mir die Quellen nicht angesehen, aber es wird Zur Not sicher noch einfacher möglich sein... eine einfache Perlfunktion (und ggf. eine leichte Anpassung von Sketches (zum Testen)), die periodisch (per AT aufgerufen) den GateWay abfragt und die Werte in ein Dummy schiebt.
Das kann man dann loggen und auch Plotten. So ist dann nicht weiter schwer die Reichweite etc. zu testen.
Dann kann man auch getrennte saubere Module für GateWay und alles andere zu erstellen. Dies erfordert dann natürlich schon einen gewissen Erstellungs- und Test-Aufwand.
Hallo Hexenmeister,
hab ich doch schon gemacht: Einen Sensor, der stumpf die Daten über USB zum Fhem rüberschubst, definiert als Jeelink-Device.
http://blog.moneybag.de/drahtloser-distanzsensor-mit-arduino-nrf24l01-und-ultraschallsensor/
Schaue dir mein Youtube-Video an und die Kommentare weiter unten. Der Sketch der einzelnen Sensoren ist ganz pfiffig gemacht, er sagt beim Start des Sensors, was für einer er ist (Feuchtigkeitssensor, Temp-Sensor etc) dann den festgelegten Kanal und den Wert (Aus, EIN, Temperatur etc.)
Nur er sagt natürlich UNKNOWN CODE, ist ja klar, weil der Jeelink ihn nicht kennt.
LG
/robin
OK, scheinbar haben einige Leute damit gute Erfahrungen gemacht. Mir gefällt es trotzdem besser, einen maximal großen Abstand zu meinem WLAN zu haben ;)
Die Integration in FHEM dürfte relativ einfach sein. Passt doch einfach JeeLink.pm fürs GateWay und z.B. mein GSD-Modul als Basis für die Sensoren (https://github.com/hexenmeister/MyFHEM/blob/master/FHEM/36_GSD.pm). Oder passt das GateWay-Sketch so, dass statt Semikolongetrennten Zahlen die Hex-Reihen rauskommen, wie bei JeeLink/GSD-Modul erwartet. ;) Die letzte dürfte die schnellste Lösung sein.
würde ich ja machen, wenn ich Perl könnte. Wie schon gesagt, die PM-Datei müsste "einfach" beim ersten Reinstecken des Moduls den Namen und den Channel notieren vom Sensor und anschließend die Werte (Temperatur, an aus) loggen... das wäre es..
@Robin,
Ich habe vor kurzem deinen fertig geflashten Jeelink für das Auslesen der Technoline Temperatursensoren erstanden.
Ich hbe das mit den MySensors in Verbindung mit dem Jeelink noch nicht ganz verstanden. Deinen Blogbeitrag finde ich aber sehr sehr interessant.
Mich würde jetzt vor allem interessieren, ob der Jeelink parallel die vorhandenen Temperatursensoren als auch die Sensoren von MySensors auslesen kann, ich möchte natürlich nixhtr noch einen zweiten Jeelink einsetzen.
Grüße,
Michael
@Roaster
JeeLink (besiert auf RFM12b) kann natürlich keine Signale von diesen Sensoren empfangen. Es ging nur um den JeeLink-Perl-Modul, nicht um die Hardware!
Zitat von: hexenmeister am 08 September 2014, 20:34:38
JeeLink (besiert auf RFM12b) kann natürlich keine Signale von diesen Sensoren empfangen. Es ging nur um den JeeLink-Perl-Modul, nicht um die Hardware!
Bedeutet nun, dass wenn man die Sensoren einsetzen möchte eine weitere Hardware benötigt :-\
Zitat von: Roaster am 08 September 2014, 20:46:01
Bedeutet nun, dass wenn man die Sensoren einsetzen möchte eine weitere Hardware benötigt :-\
Selbstverständlich, Du brauchst kompatiblen Transmitter.
@fh168
Jut, dann eben andersrum - kannst Du C? Wenn Du die Sketches bezüglich der (serielen) API JeeLink-kompatibel anpassen willst, helfe ich Dir die Sensoren mit dem GSD-Modul in FHEM zu integrieren. Incl. Autocreate ;)
Hallo,
nur mal so nebenbei erwähnt ;)
denkt ihr bitte daran, wenn der Stein nun ins Rollen gekommen ist und man sich wirklich Gedanken zwecks Umsetzung macht,
das es Nodes (Clients) gibt, welche Signale vom Gateway empfangen und dann dementsprechend reagieren.
zum Beispiel: Node/Client "Relais"
In der Kombination mit einen "Motion-Sensor" oder einfach nur einen "Kontakt/Schalter" würden dann die Signale über FHEM dementsprechend Empfangen, Ausgewertet und ggf. neue Befehle gesendet.
Also beim betätigen eines "Wandtasters/Schalters" oder bei Erfassung eines "Objektes", dann schalte das "Relais im 1. OG" ein.
Oder bei Unterschreiten eines Wasserspiegels oder Feuchtigkeitsgrad -> aktiviere die Bewässerungspumpe.
Bei den Sensoren ist es auch mgl. den Status entweder abzufragen oder sich periodisch senden zu lassen.
Das es quasi eine Bidirektionale Kommunikation bei "MySensors" gibt und das zu den Preis finde ich eben sehr interessant.
Werden nur periodisch Werte gesendet (z.Bsp. alle 15 Minuten die Temperatur) kann man die Sensoren in den "Sleep" schicken um Energie zu sparen. Somit wäre ein Batterieversorgung für solche Sensoren auch überlegenswert. Aber das ist hier gerade ein bisschen OT ::) Ich werde mich demnächst noch mit der Batteriegeschichte beschäftigen, da man "angeblich" fast 2 Jahre mit einen Batteriesatz auskommen soll.
Ich danke schon einmal alle, bei den ich etwas Interesse für dieses Projekt geweckt habe und sich schon einmal Gedanken für eine eventuelle Umsetzung gemacht haben oder ggf. noch machen werden.
DANKE
Mit den Batterien ist immer schon so eine Sache... Der Arduino kann schon sehr sparsam betrieben werden (http://s6z.de/cms/index.php/arduino/nuetzliches/9-winterschlaf-fuer-arduino). K.A. Was dieser Transmitter an Energie verbrät, aber 1 Jahr halte ich schon für realistisch (meine ATtiny/RFM12b Sensoren überleben mit einem 3,7V Li-Akku auch in etwa diese Zeitrahmen).
Ins Rollen ist IMHO noch gar nichts gekommen. Eine vollständige Unterstützung eines ganz neuen Systems ist eine anspruchsvolle Aufgabe. Da ich selbst diese Teile wohl nicht betreiben werde (ich habe schon 2 verschiedene Funksysteme am Laufen, evtl. kommt noch zwave dazu), habe ich kein Interesse und auch keine Zeit dafür. Eine andere Geschichte ist, wenn man die Hardware nutzt und die Firmware mit bereits unterstützten Modulen (JeeLink) kompatibel macht (wahrscheinlich reicht es dafür die Gateway-Firmware zu modifizieren). Und da biete ich meine Unterstützung bei der Anpassung von GSD-Modul für die einzelne Sensor-Typen. Über Aktoren sprechen wir derzeit noch gar nicht, wäre natürlich theoretisch auch möglich... Ich denke jedoch, spätestens, wenn man 250V schalten will, sollte man unbedingt auf fertige Geräte mit CE-Zeichen zurückgreifen. Allein schon aus versicherungstechnischen Gründen.
Hi Hexenmeister,
meine Bewässerungspumpe arbeitet mit 12V ;) , war wohl einer besten Anschaffungen die ich jemals gemacht habe, günstig, richtig Druck, Markengerät!, so etwas für den Preis habe ich ehrlich noch nie gesehen, hatte ich beim Campingauststatter über Amazon erworben :-) aber das mal nur so nebenbei 8)
Damit bewässere ich mein 5 m2 Gewächshaus (teils 2 Etagen) + Hochbeet mit den Gardena Micro-Drip System, nur war die Gardena "kleine" Pumpe dieses Jahr etwas überfordert, deshalb entschied ich mich für diese. Eigentlich war geplant die Gardena und die "neue" Pumpe von der Bewässerung dementsprechend aufzuteilen, doch nun erledigt das eine "super kleine" Minipumpe 8)
Es wäre natürlich schön, wenn entweder die Sensoren bei zu geringen Feuchtigkeitsgrad oder zu hoher Temperatur (wenn sich der Wetterdienst wieder einmal irrt) die Pumpe einzuschalten, bzw. wenn ich es per Web manuell mache.
Der Zugriff auf den FHEM Server über das INET, habe ich ja schon, dann bräuchte ich diese Geschichte nicht noch über ein Terminal zu machen.
Nur so mal als Beispiel ;)
und du weist ja, die Hoffnung stirbt zum Schluß :)
Das über FH20 oder andere Systeme zu machen ist wirklich teuer und es geht nur in eine Richtung oder noch teuerer wenn man es in beide Richtungen machen will!
Wenn ich sage schalte die Pumpe ein, dann sendet dieses System (z.Bsp. FH20) "Pumpe ein", ob es empfangen wurde und die Pumpe wirklich "An" ist, kann ich nur hoffen, da ich keine Rückmeldung bekomme.
Aber ich finde es schon mal "Gut", das sich einige User den Threat durchlesen (momentan ca. 300!) und sich vielleicht auch für dieses System "MySenors.org (http://mysenors.org)" interessieren. Vielleicht ist ja auch der ein oder andere Programmierer dabei, der sein Wissen bei der Umsetzung einfließen läßt.
Das würde ja dann nicht nur einen einzelnen sonder der Allgemeinheit zu Gute kommen :-)
Zitat von: Roaster am 08 September 2014, 19:45:55
@Robin,
Ich habe vor kurzem deinen fertig geflashten Jeelink für das Auslesen der Technoline Temperatursensoren erstanden.
Ich hbe das mit den MySensors in Verbindung mit dem Jeelink noch nicht ganz verstanden. Deinen Blogbeitrag finde ich aber sehr sehr interessant.
Mich würde jetzt vor allem interessieren, ob der Jeelink parallel die vorhandenen Temperatursensoren als auch die Sensoren von MySensors auslesen kann, ich möchte natürlich nixhtr noch einen zweiten Jeelink einsetzen.
Grüße,
Michael
hast eine PM von mir.
Jeelink-Lacrosse und Mysensor-Gateway Sketch passen auf einen Nano drauf. Du benötigst, wie Hexenmeister schon sagt, noch mindestens 2 von den nRF24L01 (Sender / Empfänger), wobei der erste nRFL2401 als Transceiver zusätzlich auf dem "Jeelink"-Lacrosse-Nano angelötet wird.
Läuft bei mir seit Monaten stabil, nur leider kein echtes Interface zum fhem, lediglich im Fhem-Monitor sehe ich die Alarme, sie mein Blogbeitrag in den Kommentaren.
Robin
@fh555
Verstehe, 12V kann man schon schalten.
Ich finde es auch wichtig, dass das System eine Rückmeldung gibt. Daher verwende ich HomeMatic. Ich finde, erlich gesagt, für das gebotene witd hier nicht zu viel verlangt. Mit 30 Euro für den Transmitter und ab 17 EUro für den Schaltaktor-Bausatz bist Du dabei.
http://www.elv.de/homematic-schaltaktor-fuer-batteriebetrieb-komplettbausatz.html
http://www.elv.de/homematic-4-kanal-funk-schaltaktor-fuer-batteriebetrieb-bausatz.html
http://www.elv.de/homematic-8-kanal-empfangsmodul.html
Basteleien lohnen sich eingentlich nur, wenn man auch Spaß am Basteln hat. Aber gut, warum auch nicht...
Ok, my school german isn't what it used to be and I can't understand much of this thread. ;)
But I'm happy to answer any questions regarding MySensors if you need help getting started with a plugin for FHem.
Thanks for the offer. My English is also sufficient for reading rather than writing. ;)
But it must be enough.
I like the good documentation, easy way of implementation of new sensors and many examples in the MySensors project. Not so nice that each measured value is transmitted individually. The wasted bandwidth in the case of a bigger quantity of sensors.
There are currently no questions. The integration should not be very difficult. But I do not see any great interest exists. I ordered some transceiver boards and want to try this in terms of range. If this will be good, I will possibly create a FHEM module. The post from China needs a lot of time unfortunately. :(
Yep, the china-post-lottery is always a fun surprise ;)
Bandwidth is usually not a problem at 2.4GHz. The modules can even be used to transmit audio (but I haven't created any examples of this yet though).
Lower frequencies has an advantage on distance and that's why I implemented the mesh functionality in the library. But I haven't really needed it in my 180sqm house yet. :D
Mesh is cool of course :)
Audio would be theoretically interesting.
I use in my house RFM12B with 868MHz. Unfortunately, the ceilings contain so much iron that the range is just as sufficient. I'm looking forward to the tests at 2.4 GHz. ;)
It also could be usefull to implement mqtt-support in fhem. This would allow the use of MySensors mqtt-gateway. There's also es existing perl-module to interface with MQTT (both on CPAN (http://search.cpan.org/dist/Net-MQTT/) and github (https://github.com/beanz/net-mqtt-perl)).
Prima, es geht hier weiter. And welcome HEK to this forum, I wrote an article in my blog a few month ago: http://blog.moneybag.de/drahtloser-distanzsensor-mit-arduino-nrf24l01-und-ultraschallsensor/ to advertise your Website mySensors.org for fhem.
Nicht so schnell.
Ich sehe immer noch nicht viele Interessenten hier. Nicht unter Entwickler und auch nicht bei den (potentiellen) Nutzern.
Ich habe mir ein Transmitterpärchen bestellt und will erstmal schauen, wie die Reichweite und Stromverbrauch aussehen.
Sollte beides akzeptabel sein, will ich Module für SerialGateway und die wichtigsten Sensoren erstellen. Dann sehen wir weiter.
MQTT ist sicherlich nicht uninteressant, hätten wir konkretten weiteren Nutzen dafür, außer MySensors?
ich hab grade mal angefangen Net::MQTT in ein fhem-modul zu wrappen. Die Kommunikation ist an sich ist ziemlich straingforward. Aber darüber, wie man die Nachrichten dann auf konkrete readings abbildet, ob man spezialisierte Child-devices schreiben sollte, oder ob das generisch sinnvoll geht, darüber muss ich mir erst noch mal einen Kopf machen. Den notwendigen mqtt-broker kann man auf Linux in form von mosquitto (http://mosquitto.org/) jedenfalls in sekunden installieren und auch gleich (auch mit den beispielsscripten von Net::MQTT) nutzen.
Ich Hab jetzt noch nichts anderes im Blick was konkret über mqtt anzubinden wäre. Ich finde das aber einfach so ziemlich interessant und potentiell nützlich, ist halt ein standartisiertes Protokoll, über dass ich beim Stichwort 'Internet of Things' in den letzten Monaten immer wieder gestolpert bin. Man könnte damit nicht nur weitere Sensoren an fhem anbinden, sondern auch in die Gegenrichtung von fhem versorgte Devices nach mgtt publizieren oder darüber steuern lassen. Auf der anderen Seite kann dann ja z.B. eine Arduino-app oder eine andere Visualisierungsoberfläche arbeiten, die gar nicht speziell für FHEM geschrieben wurde. Mal sehen, was daraus wird...
Ich habe mich etwas in MQTT eingelesen.
Ja, die Vorstellung ist schon cool.
Ganz salopp: Man nehme einen Temp.Sensor, tue es in die Küche in den Kühlschrank, teile ihm das auch mit und plötzlich schreit er in die ganze Welt (aus dem Kühlschrank ;) ) die Innentemperatur. Der FHEM-Server sieht das und legt schon mal die Objekte für Küche und Kühlschrank gleich mit dem Temperaturwert ;)
Leider kenn FHEM gar keine Objekte und Räume :(
Auch die MQTT Implementierung in MySensors macht nicht viel mehr als in etwa folgendes zu übertragen: /MyMQTT/SenderID/SensorID/READING_TYP = WERT
Da müsste man das irgendwo noch mappen, zu den 'reellen' Räumen und Gegenständen. Dies müsste wohl schon im GateWay passieren.
Aber das Thema ist ja auch noch viel größer, als FHEM oder MySensors. Man braucht einen externen Brocker, eine irgendwie geartete Verwaltung und, und, und...
Interessant, was daraus wird.
es gibt hier: http://forum.fhem.de/index.php/topic,27291.msg202969.html#msg202969 (http://forum.fhem.de/index.php/topic,27291.msg202969.html#msg202969) auch gerade die idee eventuell mqtt zu verwenden. vielleicht wäre eine generische fhem/mqtt schnittstelle ja noch für andere dinge interessant.
gruss
andre
Zitatvielleicht wäre eine generische fhem/mqtt schnittstelle ja noch für andere dinge interessant.
Ja, vielleich, man muss aber etwas konkretisieren. In meiner Vorstellung würde das schon auf einen nicht unerheblichen Aufwand hinauslaufen. Vielleicht sollen wir (in einem Extra-Thread) ein möglichst vollständiges System skizzieren. Rolle von FHEM, Mapping, Regeln für Autocreate...
Da hat aber mit MySensors eingentlich nichts mhr zu tun.
hab mal eine generische mqtt-bridge (http://forum.fhem.de/index.php/topic,27532.0.html) gebastelt...
Gruß,
Norbert
Jetzt muss man denn MySensor-Geräten noch beibringen, sich als fhem/wohnzimmer/temperatur zu melden.
Dafür nimmt man dann wohl das mqtt_gateway (http://mysensors.org/build/mqtt_gateway).
Ok, die topics heißen da natürlich anders, aber man kann mit MQTT_DEVICE jedes mqtt-Topic auf jedes FHEM-Reading mappen. Für nicht-fhem-Geräte wie die MySensor-sensoren, die nicht fhem steuern, sondern Werte an fhem reporten sollen, muss man das aktuell auf dummies abbilden. An der Stelle ist das MQTT_DEVICE sicher noch ausbaufähig, damit man in dem Fall weniger Redundanz in die Konfiguration bekommt.
Gruß,
Norbert
Ja, klar, ich überlege nur, wie man diese Mapping-Orgie etwas einfcher gestallten kann...
Einerseits wäre es schön, wenn die Devices (MySensors oder was auch immer) auf die gewünschte Topics eingestellt werden könnten ('Sensor0815, Du bist jetzt 'eg/wohnzimmer' und dass du Temperatur lieferst, weiß du ja selber' => also 'eg/wohnzimmer/temperatur'). Andererseits ist die universellere FHEM-seitige Mapping auch unverzichtbar...
Der MQTT-Gateway Sketch von mySensors läuft schon mal bei mir hardwaremäßig.
Wie bekomme ich die Dateien vom mqtt_gateway (trunk) in mein Fhem rein? Alle einzeln kopieren?
Sind ja nur 2 Dateien und 1 Verzeichniss rekursiv zu kopieren.
Oder bis morgen warten und ein Update machen.
dann warte ich bis morgen. Auf einen Tag später kommt es jetzt auch nicht an.
Ich habe es gerade ausprobiert (ohne Hardware). Bei mir läuft noch nicht, habe in dem anderen Thread beschrieben.
yep, habe ich gesehen. Na ja, wird wohl nichts großes sein und schon bald gefixt werden.
gehe davon aus ;)
update im SVN, siehe anderen Thread (http://forum.fhem.de/index.php/topic,27532.msg204448.html#msg204448)
Mit den Anpassungen an MQTT_DEVICE sollte sich ein MySensors-gerät ohne dummy direkt auf eine MQTT_DEVICE-instanz abbilden lassen. Zum mappen von existierenden FHEM-devices auch mqtt-topics gibt's jetzt MQTT_BRIDGE.
Der Fehler ist mit dem DevIOSimpleWrite ist gefixed, der Hänger bei Alexander ist eventuell plattformabhängig? Hier flutschts (auf Ubuntu 14.04)
Gruß,
Norbert
Hi und supi, dass ihr die Implentierung in Betracht gezogen habt ;D
Ich habe gleich ein W5100 geordert, damit wenn ihr möchtet, ich aktiv mit testen kann.
mein aktueller Abruf wirft das raus:
Can't locate Net/MQTT/Constants.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM ./FHEM/lib) at ./FHEM/00_MQTT.pm line 30.
BEGIN failed--compilation aborted at ./FHEM/00_MQTT.pm line 30.
Da kam wohl das Verzeichnis im Lib nicht mit.
Ich denke, neue Verzeichnisse werden nicht automatisch beim Update übernommen.
Davon abgesehen, ich habe zwar diese Dateien, aber trotzdem ein anderes Error.
ich habe das verzeichnis aus dem trunk - möglicherweise umständlich mit ftp - auf mein fhem gebeamt.
war sogar ohne fehlermeldung.
nun frage ich mich wie ich bspw. ein reed-schalter da lesemäßig ansprechen kann.
und woran sehe ich, ob meine Netzwerkkarte vom arduino überhaupt funktioniert? Steht dann in den Properties von fhem dann connect?
define mySensors MQTT 192.168.178.234:1883 reicht ja nicht
DEF
192.168.178.234:1883
DeviceName
192.168.178.234:1883
NAME
mySensors
NEXT_OPEN
1412279472
NOTIFYDEV
global
NR
3
NTFY_ORDER
50-mySensors
PARTIAL
STATE
disconnected
TYPE
MQTT
msgid[/code]
Serial monitor wirft bei geschlossenen Reed-Kontakt folgendes aus:
Started!
0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:
Zitat von: fh168 am 02 Oktober 2014, 21:52:31
nun frage ich mich wie ich bspw. ein reed-schalter da lesemäßig ansprechen kann.
und woran sehe ich, ob meine Netzwerkkarte vom arduino überhaupt funktioniert? Steht dann in den Properties von fhem dann connect?
Naja es scheint sich nicht konnecten zu können. Wenn die Adresse stimmt, dann funktioniert einer der beiden Teilehmen (FHEM-Modul vs. MySensors-Gateway Sketch) nicht korrekt.
ok, ich forsche weiter
wie kann man antesten, beim arduino modul die netzwerkkarte funktioniert?
Das wuerde mich auch interessieren, da weder ein ping, web oder telnet Verbindung auf die IP:Port funktioniert.
Eine serielle Ausgabe über den Lan Gateway funktioniert, somit melden sich die Sensoren schon einmal am Gateway an.
so ich bin nun einen Schritt weiter :-)
Eiin Ping und eine Telnet Verbindung funktioniert. Jetzt den Trunk in fhem/lib/net eingepflegt mit den entsprechenden Rechten.
In die fhem.cfg den Eintrag "define MQTT_MySensors MQTT 192.168.100.250:1883" ergänzt.
Nun bekomme ich folgende Fehlermeldungen :-(
Constant subroutine main::MQTT_PINGRESP redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 61.
Constant subroutine main::MQTT_CONNECT_ACCEPTED redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 61.
Constant subroutine main::MQTT_UNSUBSCRIBE redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 61.
Constant subroutine main::MQTT_QOS_AT_LEAST_ONCE redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 61.
Constant subroutine main::MQTT_DISCONNECT redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 61.
Constant subroutine main::MQTT_PUBREL redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 61.
Constant subroutine main::MQTT_CONNECT_REFUSED_SERVER_UNAVAILABLE redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 61.
Constant subroutine main::MQTT_QOS_AT_MOST_ONCE redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 61.
Constant subroutine main::MQTT_UNSUBACK redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 61.
Constant subroutine main::MQTT_CONNECT redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 61.
Constant subroutine main::MQTT_CONNECT_REFUSED_NOT_AUTHORIZED redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 61.
Constant subroutine main::MQTT_PINGREQ redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 61.
Constant subroutine main::MQTT_PUBCOMP redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 61.
Constant subroutine main::MQTT_PUBLISH redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 61.
Constant subroutine main::MQTT_CONNECT_REFUSED_IDENTIFIER_REJECTED redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 61.
Constant subroutine main::MQTT_SUBACK redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 61.
Constant subroutine main::MQTT_PUBACK redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 61.
Constant subroutine main::MQTT_CONNACK redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 61.
Constant subroutine main::MQTT_SUBSCRIBE redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 61.
Constant subroutine main::MQTT_CONNECT_REFUSED_UNACCEPTABLE_PROTOCOL_VERSION redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 61.
Constant subroutine main::MQTT_CONNECT_REFUSED_BAD_USER_NAME_OR_PASSWORD redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 61.
Constant subroutine main::MQTT_QOS_EXACTLY_ONCE redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 61.
Constant subroutine main::MQTT_PUBREC redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 61.
dann
2014.10.03 00:46:48 1: 192.168.100.250:1883 disconnected, waiting to reappear (MQTT_MySensors)
2014.10.03 00:46:48 1: 192.168.100.250:1883 reappeared (MQTT_MySensors)
Gruß Jens
Das sieht schon mal gut aus
connection
active
2014-10-03 10:24:37
jetzt nur noch einen Sensor einbinden, geht das mit
subscribeSet
45/0/V_9/set
??
Danke schon mal an fh555 :-)
Sensoren melden sich selber :-),
Screenshot vom Arduino - Serial Monitor
MyMQTT/20/0/V_TRIPPED
>>30 18 00 15 4D 79 4D 51 54 54 2F 32 30 2F 30 2F 56 5F 54 52 49 50 50 45 44 30
0;0;3;0;9;read: 20-20-0 s=0,c=1,t=16,pt=2,l=2:1
MyMQTT/20/0/V_TRIPPED
>>30 18 00 15 4D 79 4D 51 54 54 2F 32 30 2F 30 2F 56 5F 54 52 49 50 50 45 44 31
0;0;3;0;9;read: 20-20-0 s=0,c=1,t=16,pt=2,l=2:0
MyMQTT/20/0/V_TRIPPED
>>30 18 00 15 4D 79 4D 51 54 54 2F 32 30 2F 30 2F 56 5F 54 52 49 50 50 45 44 30
0;0;3;0;9;read: 20-20-0 s=0,c=1,t=16,pt=2,l=2:1
MyMQTT/20/0/V_TRIPPED
>>30 18 00 15 4D 79 4D 51 54 54 2F 32 30 2F 30 2F 56 5F 54 52 49 50 50 45 44 31
0;0;3;0;9;read: 45-45-0 s=3,c=1,t=16,pt=2,l=2:0
MyMQTT/45/3/V_TRIPPED
>>30 18 00 15 4D 79 4D 51 54 54 2F 34 35 2F 33 2F 56 5F 54 52 49 50 50 45 44 30
0;0;3;0;9;read: 45-45-0 s=3,c=1,t=16,pt=2,l=2:1
MyMQTT/45/3/V_TRIPPED
>>30 18 00 15 4D 79 4D 51 54 54 2F 34 35 2F 33 2F 56 5F 54 52 49 50 50 45 44 31
>>D0 00
<<C0 00
>>D0 00
<<C0 00
>>D0 00
Updata reedkontakt (1 / 0) Zustände
define mqtt MQTT 192.168.178.234:1883
define mqtt_Reedschalter2 MQTT_DEVICE
attr mqtt_Reedschalter2 IODev mqtt
attr mqtt_Reedschalter2 stateFormat transmission-state
attr mqtt_Reedschalter2 subscribeReading_state MyMQTT/45/3/V_TRIPPED
Ergebnis sieht dann so aus.
Readings
state
1
2014-10-03 12:43:55
transmission-state
publish received
2014-10-03 12:43:54
Einen herzlichen Dank an die Programmierer!!!
Wenn das ausgerollt wird, werde ich einen Blog-Beitrag darüber schreiben. Ein interessantes Thema.
Kann man das ganze nicht USB laufen lassen zum Raspi hin? Jetzt habe ich wieder ein Netzwerkkabel hier rumliegen..mag ich nicht.
Das Bild zeigt einen Arduino Uno mit einem Net-Shield (W 5100 Ethernet-Module) und einem Feuchtigkeitssensor. Meinen Distanzsensor, den ich damals mal gebaut habe, habe ich leider schon wieder auseinandergerupft ;-): http://blog.moneybag.de/drahtloser-distanzsensor-mit-arduino-nrf24l01-und-ultraschallsensor/
(http://blog.moneybag.de/wp-content/uploads/2014/10/mysensors.jpg)
Robin
Per usb geht nicht (ohne weiteres) mit MQTT.
Schade, wieder ein Kabel mehr.
Die Software läuft stabil, habe schon den ganzen Tag das Ding am rennen mit zwei Sensoren.
robin
mqtt über USB wäre vom Protokoll her kein Problem - mqtt arbeit ja mit einer dauerhaften Socket-verbindung, über die alles gestreamt wird. Nach meinem Verständnis sollte man das ganz einfach mit socat von USB nach TCP/IP umsetzen können (USB mir virtueller serieller Schnittstellt -> socat -> socket-verbindung nach mqtt). Ich weiß allerdings nicht, wie robust das gegen Ausfall oder Neustart einer der Komponenten wäre.
die fhem MQTT-module implementieren selber jedenfalls keinen Broker, sondern nur den mqtt-client. Deshalb kann man die MQTT-bridge nicht so ohne weiteres direkt über USB mit dem Modul verbinden lassen. Aber dass muss ich mir noch mal im Detail ansehen (also im Source-code der mqtt-bridge), ob die nicht auch mit geringen Änderungen mit einem mqtt-client reden könnte zu dem sie über einen Stream (also z.B. USB) direkt verbunden wäre.
Gruß,
Norbert
Hallo Norbert,
eilt alles nicht. Ist ein nice to have. Ich bin schon glücklich das endlich diese Technologie jetzt zur Verfügung steht. Danke nochmals dafür.
Ich habe es bisher geschafft, ein Reed-Kontakt von MySensors in Fhem zu implementieren. Siehe letzten Post. Reicht eigentlich für mich auch. Alle anderen Sketches (Temperaturmodule etc.) werden bei mir nicht automatisch erkannt.
robin
Hallo,
so ich habe es nun auch endlich am Laufen, da mein w5100 heute endlich gekommen ist.
Einige Sensoren habe ich schon erfolgreich ohne größere Probleme ins System integrieren können.
Wenn ich demnächst (in ca. 3 Wochen) mehr Zeit habe, nehme ich das mit den ENC28J60 noch einmal in Angriff,
da das noch eine kostengünstigere und vorallem kleiner Variante ist.
Bis dahin sollten auch meine restlichen Teile aus China eingetroffen sein :-)
Gruß Jens
Zitat von: fh555 am 08 Oktober 2014, 22:34:20
Wenn ich demnächst (in ca. 3 Wochen) mehr Zeit habe, nehme ich das mit den ENC28J60 noch einmal in Angriff,
Wie groß ist der mqtt-bridge Sketch denn, wenn man ihn für den W5100 compiliert? (Die ENC28J60-variante braucht nämlich ein paar kb mehr).
Gruß,
Norbert
Ich habe ds selbst zwar nicht ausprobiert, aber laut Hersteller-Seite soll das auch mit ENC28J60 gehen.
Hallo Hexenmeister,
der Platz reicht für den ENC28J60 zur Zeit nicht aus (Nano mit FTDI). Ich habe als Alternative den Uno mit Network-Shield genommen, klappt. (Siehe Fotos oben)
LG
/robin
Oh, Du hast recht, das steht nur bei dem 'nicht MQTT'-Sketch dran:
ZitatEnable your Ethernet module as illustrated below:
#include <UIPEthernet.h> // Use this if you have attached a Ethernet ENC28J60 shields
//#include <Ethernet.h> // Use this for WizNET module and Arduino Ethernet Shield
also geht nicht...
bekommt man das softwaremäßig hin, das alles auf einem Nano mit ENC28J60 draufpasst? Es fehlt nur knapp 1 kb.
UDP abzuschalten indem man in der uipethernet-conf.h (https://github.com/ntruchsess/arduino_uip/blob/master/utility/uipethernet-conf.h) UIP_CONF_UDP auf 0 setzt spart ca. 5kb (dann braucht der Sketch eine feste IP und der mqtt-server mit ip-addresse statt hostnamen angegeben werden, weil dann DHCP und DNS nicht mehr geht.)
Beim RAM-bedarf kann man mit UIP_CONF_MAX_CONNECTIONS 1 einiges sparen. Der mqtt-client sollte nach meinem Verständnis mit 1 offenen Socketverbindung auskommen.
Gruß,
Norbert
hallo,
werde ich ausprobieren. Der mySensors-gateway-MQTT-Sketch benötigt sowieso eine feste IP. Das würde ja passen.
und ein neues Problem seit den FHEM-Update (gestern und heute).
Ich hatte gestern u.a. die Updates MQTT, MQTT_Bridge, MQTT_Device per "fhem update" eingespielt und anschließend ein "shutdown restart" per "FHEM-Console" durchgeführt. Seitdem läuft der MQTT Gateway garnicht bzw. instabil.
Hat sich in den Definitionen der Geräte etwas geändert?
Momentan spreche ich mein Gateway wie folgt an:
define MQTT_MySensors MQTT 192.168.100.250:1883
set MQTT_MySensors connect
und die Geräte definiere ich
define mqtt_schalter1 MQTT_DEVICE
attr mqtt_schalter1 IODev MQTT_MySensors
attr mqtt_schalter1 alias Schalter 1
#attr mqtt_schalter1 stateFormat transmission-state
attr mqtt_schalter1 stateFormat state
attr mqtt_schalter1 subscribeReading_state MyMQTT/10/3/V_TRIPPED
attr mqtt_schalter1 room MQTT-Test
hat sich dahingehend etwas geändert?
Ich hatte testweise die alten Files wieder hergestellt um die Hardware auszuschließen und es funktionierte sofort wieder.
Heute hatte ich dann das "neuste Update" eingespielt und jetzt ist es so, dass entweder irgendwann ein Timeout kommt und er disconnected ist ein manueller connect funktioniert von ca. 10 Versuchen 1 mal. Ein Neustart vom Hardware-Gateway" bringt auch nichts. Ein FHEM "shutdown restart" oder das Ändern der fhem.cfg mit anschließenden abspeichern bringt manchmal die Geschichte wieder zum laufen.
Gibt es ein Diskussion-Thread wo sich die Entwickler für die Module austauschen, damit man ggf. solche Fehler gleich melden könnte?
Gruß Jens
Hallo,
ich habe über dieses Thema mal ein Blog-Beitrag geschrieben und ein kurzes youtube-video gedreht.
http://blog.moneybag.de/fhem-sensoren-an-fhem-mit-nrf24l01-transceiver/
LG
/robin
Hallo Jens,
Zitat von: fh555 am 10 Oktober 2014, 23:30:27
und ein neues Problem seit den FHEM-Update (gestern und heute) ... Seitdem läuft der MQTT Gateway garnicht bzw. instabil.
define MQTT_MySensors MQTT 192.168.100.250:1883
set MQTT_MySensors connect
das 'set MQTT_MySensors connect' ist unnötig, das MQTT-modul connected selbständig. Das set connect-kommando ist mehr zum testen.
An der Semantik der define-kommandos hat sich nix geändert. Ich habe zwischenzeitlich nach mqtt-spec Quality-Of-Service implementiert (http://forum.fhem.de/index.php/topic,27532.msg206364.html#msg206364), vieleicht ist da noch was fehlerhaft. Kannst Du bitte logs mit 'attr verbose 5' an allen beteiligten Devices (MQTT + MQTT_DEVICE) posten, in denen man Dein Problem nachvollziehen kann?
Gruß,
Norbert
Beide geräte wurden zum Start des Tests neu gestartet.
Erst der FHEM Server, danach der MQTT Gateway
2014.10.12 23:40:22 0: Server started with 47 defined entities (version $Id: fhem.pl 6730 2014-10-09 19:21:23Z rudolfkoenig $, os linux, user fhem, pid 3230)
2014.10.12 23:40:22 5: MQTT MQTT_MySensors message received: ConnAck/at-most-once Connection Accepted
2014.10.12 23:40:22 5: MQTT MQTT_MySensors message sent: Subscribe/at-least-once 1 MyMQTT/71/0/V_LIGHT_LEVEL/at-most-once
2014.10.12 23:40:22 5: SW: 821e000100194d794d5154542f37312f302f565f4c494748545f4c4556454c00
2014.10.12 23:40:22 5: MQTT MQTT_MySensors message sent: Subscribe/at-least-once 2 MyMQTT/60/0/V_TEMP/at-most-once
2014.10.12 23:40:22 5: SW: 8217000200124d794d5154542f36302f302f565f54454d5000
2014.10.12 23:40:22 5: MQTT MQTT_MySensors message sent: Subscribe/at-least-once 3 MyMQTT/60/1/V_TEMP/at-most-once
2014.10.12 23:40:22 5: SW: 8217000300124d794d5154542f36302f312f565f54454d5000
2014.10.12 23:40:22 5: MQTT MQTT_MySensors message sent: Subscribe/at-least-once 4 MyMQTT/10/3/V_TRIPPED/at-most-once
2014.10.12 23:40:22 5: SW: 821a000400154d794d5154542f31302f332f565f5452495050454400
2014.10.12 23:40:22 5: SW: 8a1a000400154d794d5154542f31302f332f565f5452495050454400
2014.10.12 23:40:22 5: SW: 8a1e000100194d794d5154542f37312f302f565f4c494748545f4c4556454c00
2014.10.12 23:40:22 5: SW: 8a17000300124d794d5154542f36302f312f565f54454d5000
2014.10.12 23:40:22 5: SW: 8a17000200124d794d5154542f36302f302f565f54454d5000
2014.10.12 23:40:22 5: MQTT MQTT_MySensors message received: PingResp/at-most-once
2014.10.12 23:40:22 5: MQTT MQTT_MySensors message received: SubAck/at-most-once 1/at-most-once
2014.10.12 23:40:22 5: MQTT MQTT_MySensors message received: SubAck/at-most-once 2/at-most-once
2014.10.12 23:40:23 5: MQTT MQTT_MySensors message received: SubAck/at-most-once 3/at-most-once
2014.10.12 23:41:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.12 23:41:14 5: SW: c000
2014.10.12 23:42:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.12 23:42:14 5: SW: c000
2014.10.12 23:43:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.12 23:43:14 5: SW: c000
2014.10.12 23:44:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.12 23:44:14 5: SW: c000
2014.10.12 23:44:14 1: 192.168.100.250:1883 disconnected, waiting to reappear (MQTT_MySensors)
2014.10.12 23:44:14 1: 192.168.100.250:1883 reappeared (MQTT_MySensors)
2014.10.12 23:44:14 5: MQTT MQTT_MySensors message sent: Connect/at-most-once MQIsdp/3/Net::MQTT::Message[3230]
2014.10.12 23:44:14 5: SW: 102600064d51497364700302003c00184e65743a3a4d5154543a3a4d6573736167655b333233305d
2014.10.12 23:44:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.12 23:44:14 5: SW: c000
2014.10.12 23:44:14 5: MQTT MQTT_MySensors message received: ConnAck/at-most-once Connection Accepted
2014.10.12 23:44:14 5: MQTT MQTT_MySensors message sent: Subscribe/at-least-once 5 MyMQTT/71/0/V_LIGHT_LEVEL/at-most-once
2014.10.12 23:44:14 5: SW: 821e000500194d794d5154542f37312f302f565f4c494748545f4c4556454c00
2014.10.12 23:44:14 5: MQTT MQTT_MySensors message sent: Subscribe/at-least-once 6 MyMQTT/60/0/V_TEMP/at-most-once
2014.10.12 23:44:14 5: SW: 8217000600124d794d5154542f36302f302f565f54454d5000
2014.10.12 23:44:14 5: MQTT MQTT_MySensors message sent: Subscribe/at-least-once 7 MyMQTT/60/1/V_TEMP/at-most-once
2014.10.12 23:44:14 5: SW: 8217000700124d794d5154542f36302f312f565f54454d5000
2014.10.12 23:44:14 5: MQTT MQTT_MySensors message sent: Subscribe/at-least-once 8 MyMQTT/10/3/V_TRIPPED/at-most-once
2014.10.12 23:44:14 5: SW: 821a000800154d794d5154542f31302f332f565f5452495050454400
2014.10.12 23:44:14 5: SW: 8a1a000800154d794d5154542f31302f332f565f5452495050454400
2014.10.12 23:44:14 5: SW: 8a17000600124d794d5154542f36302f302f565f54454d5000
2014.10.12 23:44:14 5: SW: 8a1a000400154d794d5154542f31302f332f565f5452495050454400
2014.10.12 23:44:14 5: SW: 8a17000700124d794d5154542f36302f312f565f54454d5000
2014.10.12 23:44:14 5: SW: 8a1e000500194d794d5154542f37312f302f565f4c494748545f4c4556454c00
2014.10.12 23:44:14 5: MQTT MQTT_MySensors message received: PingResp/at-most-once
2014.10.12 23:44:14 5: MQTT MQTT_MySensors message received: SubAck/at-most-once 5/at-most-once
2014.10.12 23:44:14 5: MQTT MQTT_MySensors message received: SubAck/at-most-once 6/at-most-once
2014.10.12 23:44:14 5: MQTT MQTT_MySensors message received: SubAck/at-most-once 7/at-most-once
2014.10.12 23:44:14 5: MQTT MQTT_MySensors message received: SubAck/at-most-once 4/at-most-once
2014.10.12 23:44:46 5: MQTT MQTT_MySensors message received: Publish/at-most-once MyMQTT/60/1/V_TEMP
32 36 2e 30 26.0
2014.10.12 23:44:46 5: publish received for MyMQTT/60/1/V_TEMP, 26.0
2014.10.12 23:44:46 5: publish received for MyMQTT/60/1/V_TEMP, 26.0
2014.10.12 23:44:46 5: calling readingsSingleUpdate(mqtt_Temperatur2,state,26.0,1
2014.10.12 23:44:46 5: publish received for MyMQTT/60/1/V_TEMP, 26.0
2014.10.12 23:45:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.12 23:45:14 5: SW: c000
2014.10.12 23:45:14 5: MQTT MQTT_MySensors message received: PingResp/at-most-once
2014.10.12 23:45:18 5: MQTT MQTT_MySensors message received: Publish/at-most-once MyMQTT/60/1/V_TEMP
32 36 2e 31 26.1
2014.10.12 23:45:18 5: publish received for MyMQTT/60/1/V_TEMP, 26.1
2014.10.12 23:45:18 5: publish received for MyMQTT/60/1/V_TEMP, 26.1
2014.10.12 23:45:18 5: calling readingsSingleUpdate(mqtt_Temperatur2,state,26.1,1
2014.10.12 23:45:18 5: publish received for MyMQTT/60/1/V_TEMP, 26.1
2014.10.12 23:46:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.12 23:46:14 5: SW: c000
2014.10.12 23:46:14 5: MQTT MQTT_MySensors message received: PingResp/at-most-once
2014.10.12 23:46:23 5: MQTT MQTT_MySensors message received: Publish/at-most-once MyMQTT/60/0/V_TEMP
32 36 2e 32 26.2
2014.10.12 23:46:23 5: publish received for MyMQTT/60/0/V_TEMP, 26.2
2014.10.12 23:46:23 5: calling readingsSingleUpdate(mqtt_Temperatur1,state,26.2,1
2014.10.12 23:46:23 5: publish received for MyMQTT/60/0/V_TEMP, 26.2
2014.10.12 23:46:23 5: publish received for MyMQTT/60/0/V_TEMP, 26.2
2014.10.12 23:46:55 5: MQTT MQTT_MySensors message received: Publish/at-most-once MyMQTT/60/0/V_TEMP
32 36 2e 31 26.1
2014.10.12 23:46:55 5: publish received for MyMQTT/60/0/V_TEMP, 26.1
2014.10.12 23:46:55 5: calling readingsSingleUpdate(mqtt_Temperatur1,state,26.1,1
2014.10.12 23:46:55 5: publish received for MyMQTT/60/0/V_TEMP, 26.1
2014.10.12 23:46:55 5: publish received for MyMQTT/60/0/V_TEMP, 26.1
2014.10.12 23:47:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.12 23:47:14 5: SW: c000
2014.10.12 23:47:14 5: MQTT MQTT_MySensors message received: PingResp/at-most-once
2014.10.12 23:47:18 5: MQTT MQTT_MySensors message received: Publish/at-most-once MyMQTT/10/3/V_TRIPPED
2014.10.12 23:47:18 5: publish received for MyMQTT/10/3/V_TRIPPED, 0
2014.10.12 23:47:18 5: publish received for MyMQTT/10/3/V_TRIPPED, 0
2014.10.12 23:47:18 5: publish received for MyMQTT/10/3/V_TRIPPED, 0
2014.10.12 23:47:18 5: calling readingsSingleUpdate(mqtt_schalter1,state,0,1
2014.10.12 23:47:18 2: IT set B_Dose_Fenster_LED on
2014.10.12 23:47:24 5: MQTT MQTT_MySensors message received: Publish/at-most-once MyMQTT/10/3/V_TRIPPED
31 1
2014.10.12 23:47:24 5: publish received for MyMQTT/10/3/V_TRIPPED, 1
2014.10.12 23:47:24 5: publish received for MyMQTT/10/3/V_TRIPPED, 1
2014.10.12 23:47:24 5: publish received for MyMQTT/10/3/V_TRIPPED, 1
2014.10.12 23:47:24 2: IT set B_Dose_Fenster_LED on
2014.10.12 23:47:24 5: calling readingsSingleUpdate(mqtt_schalter1,state,1,1
2014.10.12 23:47:45 2: IT set B_Dose_Fenster_LED off
2014.10.12 23:47:50 5: MQTT MQTT_MySensors message received: Publish/at-most-once MyMQTT/10/3/V_TRIPPED
2014.10.12 23:47:50 5: publish received for MyMQTT/10/3/V_TRIPPED, 0
2014.10.12 23:47:50 5: publish received for MyMQTT/10/3/V_TRIPPED, 0
2014.10.12 23:47:50 5: publish received for MyMQTT/10/3/V_TRIPPED, 0
2014.10.12 23:47:50 5: calling readingsSingleUpdate(mqtt_schalter1,state,0,1
2014.10.12 23:47:50 2: IT set B_Dose_Fenster_LED on
2014.10.12 23:47:51 5: MQTT MQTT_MySensors message received: Publish/at-most-once MyMQTT/10/3/V_TRIPPED
31 1
2014.10.12 23:47:51 5: publish received for MyMQTT/10/3/V_TRIPPED, 1
2014.10.12 23:47:51 5: publish received for MyMQTT/10/3/V_TRIPPED, 1
2014.10.12 23:47:51 5: publish received for MyMQTT/10/3/V_TRIPPED, 1
2014.10.12 23:47:51 2: IT set B_Dose_Fenster_LED on
2014.10.12 23:47:51 5: calling readingsSingleUpdate(mqtt_schalter1,state,1,1
2014.10.12 23:48:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.12 23:48:14 5: SW: c000
2014.10.12 23:48:14 5: MQTT MQTT_MySensors message received: PingResp/at-most-once
2014.10.12 23:48:32 5: MQTT MQTT_MySensors message received: Publish/at-most-once MyMQTT/60/0/V_TEMP
32 36 2e 32 26.2
2014.10.12 23:48:32 5: publish received for MyMQTT/60/0/V_TEMP, 26.2
2014.10.12 23:48:32 5: calling readingsSingleUpdate(mqtt_Temperatur1,state,26.2,1
2014.10.12 23:48:32 5: publish received for MyMQTT/60/0/V_TEMP, 26.2
2014.10.12 23:48:32 5: publish received for MyMQTT/60/0/V_TEMP, 26.2
2014.10.12 23:49:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.12 23:49:14 5: SW: c000
2014.10.12 23:49:14 5: MQTT MQTT_MySensors message received: PingResp/at-most-once
2014.10.12 23:50:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.12 23:50:14 5: SW: c000
2014.10.12 23:50:14 5: MQTT MQTT_MySensors message received: PingResp/at-most-once
2014.10.12 23:51:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.12 23:51:14 5: SW: c000
2014.10.12 23:51:14 5: MQTT MQTT_MySensors message received: PingResp/at-most-once
2014.10.12 23:52:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.12 23:52:14 5: SW: c000
2014.10.12 23:52:14 5: MQTT MQTT_MySensors message received: PingResp/at-most-once
2014.10.12 23:53:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.12 23:53:14 5: SW: c000
2014.10.12 23:53:14 5: MQTT MQTT_MySensors message received: PingResp/at-most-once
2014.10.12 23:53:55 5: MQTT MQTT_MySensors message received: Publish/at-most-once MyMQTT/60/0/V_TEMP
32 36 2e 33 26.3
2014.10.12 23:53:55 5: publish received for MyMQTT/60/0/V_TEMP, 26.3
2014.10.12 23:53:55 5: calling readingsSingleUpdate(mqtt_Temperatur1,state,26.3,1
2014.10.12 23:53:55 5: publish received for MyMQTT/60/0/V_TEMP, 26.3
2014.10.12 23:53:55 5: publish received for MyMQTT/60/0/V_TEMP, 26.3
2014.10.12 23:54:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.12 23:54:14 5: SW: c000
2014.10.12 23:54:14 5: MQTT MQTT_MySensors message received: PingResp/at-most-once
2014.10.12 23:54:27 5: MQTT MQTT_MySensors message received: Publish/at-most-once MyMQTT/60/0/V_TEMP
32 36 2e 32 26.2
2014.10.12 23:54:27 5: publish received for MyMQTT/60/0/V_TEMP, 26.2
2014.10.12 23:54:27 5: calling readingsSingleUpdate(mqtt_Temperatur1,state,26.2,1
2014.10.12 23:54:27 5: publish received for MyMQTT/60/0/V_TEMP, 26.2
2014.10.12 23:54:27 5: publish received for MyMQTT/60/0/V_TEMP, 26.2
2014.10.12 23:55:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.12 23:55:14 5: SW: c000
2014.10.12 23:55:14 5: MQTT MQTT_MySensors message received: PingResp/at-most-once
2014.10.12 23:56:04 5: MQTT MQTT_MySensors message received: Publish/at-most-once MyMQTT/60/0/V_TEMP
32 36 2e 33 26.3
2014.10.12 23:56:04 5: publish received for MyMQTT/60/0/V_TEMP, 26.3
2014.10.12 23:56:04 5: calling readingsSingleUpdate(mqtt_Temperatur1,state,26.3,1
2014.10.12 23:56:04 5: publish received for MyMQTT/60/0/V_TEMP, 26.3
2014.10.12 23:56:04 5: publish received for MyMQTT/60/0/V_TEMP, 26.3
2014.10.12 23:56:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.12 23:56:14 5: SW: c000
2014.10.12 23:56:14 5: MQTT MQTT_MySensors message received: PingResp/at-most-once
2014.10.12 23:57:08 5: MQTT MQTT_MySensors message received: Publish/at-most-once MyMQTT/60/0/V_TEMP
33 31 2e 31 31.1
2014.10.12 23:57:08 5: publish received for MyMQTT/60/0/V_TEMP, 31.1
2014.10.12 23:57:08 5: calling readingsSingleUpdate(mqtt_Temperatur1,state,31.1,1
2014.10.12 23:57:08 5: publish received for MyMQTT/60/0/V_TEMP, 31.1
2014.10.12 23:57:08 5: publish received for MyMQTT/60/0/V_TEMP, 31.1
2014.10.12 23:57:09 5: MQTT MQTT_MySensors message received: Publish/at-most-once MyMQTT/60/1/V_TEMP
32 36 2e 33 26.3
2014.10.12 23:57:09 5: publish received for MyMQTT/60/1/V_TEMP, 26.3
2014.10.12 23:57:09 5: publish received for MyMQTT/60/1/V_TEMP, 26.3
2014.10.12 23:57:09 5: calling readingsSingleUpdate(mqtt_Temperatur2,state,26.3,1
2014.10.12 23:57:09 5: publish received for MyMQTT/60/1/V_TEMP, 26.3
2014.10.12 23:57:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.12 23:57:14 5: SW: c000
2014.10.12 23:57:14 5: MQTT MQTT_MySensors message received: PingResp/at-most-once
2014.10.12 23:57:41 5: MQTT MQTT_MySensors message received: Publish/at-most-once MyMQTT/60/0/V_TEMP
32 37 2e 38 27.8
2014.10.12 23:57:41 5: publish received for MyMQTT/60/0/V_TEMP, 27.8
2014.10.12 23:57:41 5: calling readingsSingleUpdate(mqtt_Temperatur1,state,27.8,1
2014.10.12 23:57:41 5: publish received for MyMQTT/60/0/V_TEMP, 27.8
2014.10.12 23:57:41 5: publish received for MyMQTT/60/0/V_TEMP, 27.8
2014.10.12 23:57:41 5: MQTT MQTT_MySensors message received: Publish/at-most-once MyMQTT/60/1/V_TEMP
32 36 2e 37 26.7
2014.10.12 23:57:41 5: publish received for MyMQTT/60/1/V_TEMP, 26.7
2014.10.12 23:57:41 5: publish received for MyMQTT/60/1/V_TEMP, 26.7
2014.10.12 23:57:41 5: calling readingsSingleUpdate(mqtt_Temperatur2,state,26.7,1
2014.10.12 23:57:41 5: publish received for MyMQTT/60/1/V_TEMP, 26.7
2014.10.12 23:58:13 5: MQTT MQTT_MySensors message received: Publish/at-most-once MyMQTT/60/0/V_TEMP
32 37 2e 30 27.0
2014.10.12 23:58:13 5: publish received for MyMQTT/60/0/V_TEMP, 27.0
2014.10.12 23:58:13 5: calling readingsSingleUpdate(mqtt_Temperatur1,state,27.0,1
2014.10.12 23:58:13 5: publish received for MyMQTT/60/0/V_TEMP, 27.0
2014.10.12 23:58:13 5: publish received for MyMQTT/60/0/V_TEMP, 27.0
2014.10.12 23:58:13 5: MQTT MQTT_MySensors message received: Publish/at-most-once MyMQTT/60/1/V_TEMP
32 36 2e 34 26.4
2014.10.12 23:58:13 5: publish received for MyMQTT/60/1/V_TEMP, 26.4
2014.10.12 23:58:13 5: publish received for MyMQTT/60/1/V_TEMP, 26.4
2014.10.12 23:58:13 5: calling readingsSingleUpdate(mqtt_Temperatur2,state,26.4,1
2014.10.12 23:58:13 5: publish received for MyMQTT/60/1/V_TEMP, 26.4
2014.10.12 23:58:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.12 23:58:14 5: SW: c000
2014.10.12 23:58:14 5: MQTT MQTT_MySensors message received: PingResp/at-most-once
2014.10.12 23:58:45 5: MQTT MQTT_MySensors message received: Publish/at-most-once MyMQTT/10/3/V_TRIPPED
2014.10.12 23:58:45 5: publish received for MyMQTT/10/3/V_TRIPPED, 0
2014.10.12 23:58:45 5: publish received for MyMQTT/10/3/V_TRIPPED, 0
2014.10.12 23:58:45 5: publish received for MyMQTT/10/3/V_TRIPPED, 0
2014.10.12 23:58:45 5: calling readingsSingleUpdate(mqtt_schalter1,state,0,1
2014.10.12 23:58:45 2: IT set B_Dose_Fenster_LED on
2014.10.12 23:58:46 5: MQTT MQTT_MySensors message received: Publish/at-most-once MyMQTT/60/0/V_TEMP
32 36 2e 38 26.8
2014.10.12 23:58:46 5: publish received for MyMQTT/60/0/V_TEMP, 26.8
2014.10.12 23:58:46 5: calling readingsSingleUpdate(mqtt_Temperatur1,state,26.8,1
2014.10.12 23:58:46 5: publish received for MyMQTT/60/0/V_TEMP, 26.8
2014.10.12 23:58:46 5: publish received for MyMQTT/60/0/V_TEMP, 26.8
2014.10.12 23:58:46 5: MQTT MQTT_MySensors message received: Publish/at-most-once MyMQTT/60/1/V_TEMP
32 36 2e 33 26.3
2014.10.12 23:58:46 5: publish received for MyMQTT/60/1/V_TEMP, 26.3
2014.10.12 23:58:46 5: publish received for MyMQTT/60/1/V_TEMP, 26.3
2014.10.12 23:58:46 5: calling readingsSingleUpdate(mqtt_Temperatur2,state,26.3,1
2014.10.12 23:58:46 5: publish received for MyMQTT/60/1/V_TEMP, 26.3
2014.10.12 23:58:53 5: MQTT MQTT_MySensors message received: Publish/at-most-once MyMQTT/10/3/V_TRIPPED
31 1
2014.10.12 23:58:53 5: publish received for MyMQTT/10/3/V_TRIPPED, 1
2014.10.12 23:58:53 5: publish received for MyMQTT/10/3/V_TRIPPED, 1
2014.10.12 23:58:53 5: publish received for MyMQTT/10/3/V_TRIPPED, 1
2014.10.12 23:58:53 2: IT set B_Dose_Fenster_LED on
2014.10.12 23:58:53 5: calling readingsSingleUpdate(mqtt_schalter1,state,1,1
ser. Monitor nach Neustart
Started!
<<10 26 00 06 4D 51 49 73 64 70 03 02 00 3C 00 18 4E 65 74 3A 3A 4D 51 54 54 3A 3A 4D 65 73 73 61 67 65 5B 33 32 33 30 5D
>>20 02 00 00
<<C0 00
>>D0 00
<<82 1E 00 05 00 19 4D 79 4D 51 54 54 2F 37 31 2F 30 2F 56 5F 4C 49 47 48 54 5F 4C 45 56 45 4C 00
>>90 03 00 05 00
0;0;3;0;9;send: 0-0-71-71 s=0,c=1,t=23,pt=0,l=0,st=fail:
<<82 17 00 06 00 12 4D 79 4D 51 54 54 2F 36 30 2F 30 2F 56 5F 54 45 4D 50 00
>>90 03 00 06 00
0;0;3;0;9;send: 0-0-60-60 s=0,c=1,t=0,pt=0,l=0,st=fail:
<<82 17 00 07 00 12 4D 79 4D 51 54 54 2F 36 30 2F 31 2F 56 5F 54 45 4D 50 00 82 1A 00 08 00 15 4D 79 4D 51 54 54 2F 31 30 2F 33 2F 56 5F 54 52 49 50 50 45 44 00 8A 1A 00 08 00 15 4D 79 4D 51 54 54 2F 31 30 2F 33 2F 56 5F 54 52 49 50 50 45 44 00 8A 17 00 06 00 12 4D 79 4D 51 54 54 2F 36 30 2F 30 2F 56 5F 54 45 4D 50 00
>>90 03 00 07 00
0;0;3;0;9;send: 0-0-60-60 s=1,c=1,t=0,pt=0,l=0,st=fail:
<<8A 1A 00 04 00 15 4D 79 4D 51 54 54 2F 31 30 2F 33 2F 56 5F 54 52 49 50 50 45 44 00 8A 17 00 07 00 12 4D 79 4D 51 54 54 2F 36 30 2F 31 2F 56 5F 54 45 4D 50 00 8A 1E 00 05 00 19 4D 79 4D 51 54 54 2F 37 31 2F 30 2F 56 5F 4C 49 47 48 54 5F 4C 45 56 45 4C 00
>>90 03 00 04 00
0;0;3;0;9;send: 0-0-10-10 s=3,c=1,t=16,pt=0,l=0,st=ok:
0;0;3;0;9;read: 60-60-0 s=1,c=1,t=0,pt=7,l=5:26.0
MyMQTT/60/1/V_TEMP
>>30 18 00 12 4D 79 4D 51 54 54 2F 36 30 2F 31 2F 56 5F 54 45 4D 50 32 36 2E 30
<<C0 00
>>D0 00
0;0;3;0;9;read: 60-60-0 s=1,c=1,t=0,pt=7,l=5:26.1
MyMQTT/60/1/V_TEMP
>>30 18 00 12 4D 79 4D 51 54 54 2F 36 30 2F 31 2F 56 5F 54 45 4D 50 32 36 2E 31
<<C0 00
>>D0 00
0;0;3;0;9;read: 60-60-0 s=0,c=1,t=0,pt=7,l=5:26.2
MyMQTT/60/0/V_TEMP
>>30 18 00 12 4D 79 4D 51 54 54 2F 36 30 2F 30 2F 56 5F 54 45 4D 50 32 36 2E 32
0;0;3;0;9;read: 60-60-0 s=0,c=1,t=0,pt=7,l=5:26.1
MyMQTT/60/0/V_TEMP
>>30 18 00 12 4D 79 4D 51 54 54 2F 36 30 2F 30 2F 56 5F 54 45 4D 50 32 36 2E 31
<<C0 00
>>D0 00
0;0;3;0;9;read: 10-10-0 s=3,c=1,t=16,pt=2,l=2:0
MyMQTT/10/3/V_TRIPPED
>>30 18 00 15 4D 79 4D 51 54 54 2F 31 30 2F 33 2F 56 5F 54 52 49 50 50 45 44 30
0;0;3;0;9;read: 10-10-0 s=3,c=1,t=16,pt=2,l=2:1
MyMQTT/10/3/V_TRIPPED
>>30 18 00 15 4D 79 4D 51 54 54 2F 31 30 2F 33 2F 56 5F 54 52 49 50 50 45 44 31
0;0;3;0;9;read: 10-10-0 s=3,c=1,t=16,pt=2,l=2:0
MyMQTT/10/3/V_TRIPPED
>>30 18 00 15 4D 79 4D 51 54 54 2F 31 30 2F 33 2F 56 5F 54 52 49 50 50 45 44 30
0;0;3;0;9;read: 10-10-0 s=3,c=1,t=16,pt=2,l=2:1
MyMQTT/10/3/V_TRIPPED
>>30 18 00 15 4D 79 4D 51 54 54 2F 31 30 2F 33 2F 56 5F 54 52 49 50 50 45 44 31
<<C0 00
>>D0 00
0;0;3;0;9;read: 60-60-0 s=0,c=1,t=0,pt=7,l=5:26.2
MyMQTT/60/0/V_TEMP
>>30 18 00 12 4D 79 4D 51 54 54 2F 36 30 2F 30 2F 56 5F 54 45 4D 50 32 36 2E 32
<<C0 00
>>D0 00
<<C0 00
>>D0 00
<<C0 00
>>D0 00
<<C0 00
>>D0 00
<<C0 00
>>D0 00
0;0;3;0;9;read: 60-60-0 s=0,c=1,t=0,pt=7,l=5:26.3
MyMQTT/60/0/V_TEMP
>>30 18 00 12 4D 79 4D 51 54 54 2F 36 30 2F 30 2F 56 5F 54 45 4D 50 32 36 2E 33
<<C0 00
>>D0 00
0;0;3;0;9;read: 60-60-0 s=0,c=1,t=0,pt=7,l=5:26.2
MyMQTT/60/0/V_TEMP
>>30 18 00 12 4D 79 4D 51 54 54 2F 36 30 2F 30 2F 56 5F 54 45 4D 50 32 36 2E 32
<<C0 00
>>D0 00
0;0;3;0;9;read: 60-60-0 s=0,c=1,t=0,pt=7,l=5:26.3
MyMQTT/60/0/V_TEMP
>>30 18 00 12 4D 79 4D 51 54 54 2F 36 30 2F 30 2F 56 5F 54 45 4D 50 32 36 2E 33
<<C0 00
>>D0 00
0;0;3;0;9;read: 60-60-0 s=0,c=1,t=0,pt=7,l=5:31.1
MyMQTT/60/0/V_TEMP
>>30 18 00 12 4D 79 4D 51 54 54 2F 36 30 2F 30 2F 56 5F 54 45 4D 50 33 31 2E 31
0;0;3;0;9;read: 60-60-0 s=1,c=1,t=0,pt=7,l=5:26.3
MyMQTT/60/1/V_TEMP
>>30 18 00 12 4D 79 4D 51 54 54 2F 36 30 2F 31 2F 56 5F 54 45 4D 50 32 36 2E 33
<<C0 00
>>D0 00
0;0;3;0;9;read: 60-60-0 s=0,c=1,t=0,pt=7,l=5:27.8
MyMQTT/60/0/V_TEMP
>>30 18 00 12 4D 79 4D 51 54 54 2F 36 30 2F 30 2F 56 5F 54 45 4D 50 32 37 2E 38
0;0;3;0;9;read: 60-60-0 s=1,c=1,t=0,pt=7,l=5:26.7
MyMQTT/60/1/V_TEMP
>>30 18 00 12 4D 79 4D 51 54 54 2F 36 30 2F 31 2F 56 5F 54 45 4D 50 32 36 2E 37
0;0;3;0;9;read: 60-60-0 s=0,c=1,t=0,pt=7,l=5:27.0
MyMQTT/60/0/V_TEMP
>>30 18 00 12 4D 79 4D 51 54 54 2F 36 30 2F 30 2F 56 5F 54 45 4D 50 32 37 2E 30
0;0;3;0;9;read: 60-60-0 s=1,c=1,t=0,pt=7,l=5:26.4
MyMQTT/60/1/V_TEMP
>>30 18 00 12 4D 79 4D 51 54 54 2F 36 30 2F 31 2F 56 5F 54 45 4D 50 32 36 2E 34
<<C0 00
>>D0 00
0;0;3;0;9;read: 10-10-0 s=3,c=1,t=16,pt=2,l=2:0
MyMQTT/10/3/V_TRIPPED
>>30 18 00 15 4D 79 4D 51 54 54 2F 31 30 2F 33 2F 56 5F 54 52 49 50 50 45 44 30
0;0;3;0;9;read: 60-60-0 s=0,c=1,t=0,pt=7,l=5:26.8
MyMQTT/60/0/V_TEMP
>>30 18 00 12 4D 79 4D 51 54 54 2F 36 30 2F 30 2F 56 5F 54 45 4D 50 32 36 2E 38
0;0;3;0;9;read: 60-60-0 s=1,c=1,t=0,pt=7,l=5:26.3
MyMQTT/60/1/V_TEMP
>>30 18 00 12 4D 79 4D 51 54 54 2F 36 30 2F 31 2F 56 5F 54 45 4D 50 32 36 2E 33
0;0;3;0;9;read: 10-10-0 s=3,c=1,t=16,pt=2,l=2:1
MyMQTT/10/3/V_TRIPPED
>>30 18 00 15 4D 79 4D 51 54 54 2F 31 30 2F 33 2F 56 5F 54 52 49 50 50 45 44 31
<<C0 00
>>D0 00
0;0;3;0;9;read: 60-60-0 s=0,c=1,t=0,pt=7,l=5:26.6
MyMQTT/60/0/V_TEMP
>>30 18 00 12 4D 79 4D 51 54 54 2F 36 30 2F 30 2F 56 5F 54 45 4D 50 32 36 2E 36
0;0;3;0;9;read: 60-60-0 s=0,c=1,t=0,pt=7,l=5:26.5
MyMQTT/60/0/V_TEMP
>>30 18 00 12 4D 79 4D 51 54 54 2F 36 30 2F 30 2F 56 5F 54 45 4D 50 32 36 2E 35
<<C0 00
>>D0 00
Momentan läüft es, kommt nur darauf wie lange .....
Momentan in den jetzigen Testbetrieb:
Schalter1
Temperatur 1 + 2
Mit den Definitionen:
define MQTT_MySensors MQTT 192.168.100.250:1883
#set MQTT_MySensors connect
attr MQTT_MySensors keep-alive 60
attr MQTT_MySensors verbose 5
# #####################################################
# MQTT_DEVICE / NRF24L01+ / MySensors / 2,4 Ghz
# *****************************************************
define mqtt_schalter1 MQTT_DEVICE
attr mqtt_schalter1 IODev MQTT_MySensors
attr mqtt_schalter1 alias Schalter 1
attr mqtt_schalter1 stateFormat transmission-state
#attr mqtt_schalter1 stateFormat state
attr mqtt_schalter1 subscribeReading_state MyMQTT/10/3/V_TRIPPED
attr mqtt_schalter1 room MQTT-Test
attr mqtt_schalter1 verbose 5
#define mqtt_pir1 MQTT_DEVICE
#attr mqtt_pir1 IODev MQTT_MySensors
#attr mqtt_pir1 alias Pir 1
#attr mqtt_pir1 stateFormat state
#attr mqtt_pir1 subscribeReading_state MyMQTT/40/1/V_TRIPPED
#attr mqtt_pir1 room MQTT-Test
define Pflanze MQTT_DEVICE
attr Pflanze IODev MQTT_MySensors
#attr Pflanze stateFormat transmission-state
attr Pflanze stateFormat state
attr Pflanze subscribeReading_state MyMQTT/71/0/V_LIGHT_LEVEL
attr Pflanze room MQTT-Test
define mqtt_Temperatur1 MQTT_DEVICE
attr mqtt_Temperatur1 IODev MQTT_MySensors
#attr mqtt_Temperatur1 stateFormat transmission-state
attr mqtt_Temperatur1 stateFormat state
attr mqtt_Temperatur1 subscribeReading_state MyMQTT/60/0/V_TEMP
attr mqtt_Temperatur1 room MQTT-Test
attr mqtt_Temperatur1 verbose 5
define mqtt_Temperatur2 MQTT_DEVICE
attr mqtt_Temperatur2 IODev MQTT_MySensors
#attr mqtt_Temperatur2 stateFormat transmission-state
attr mqtt_Temperatur2 stateFormat state
attr mqtt_Temperatur2 subscribeReading_state MyMQTT/60/1/V_TEMP
attr mqtt_Temperatur2 room MQTT-Test
attr mqtt_Temperatur2 verbose 5
define schalter1machwas notify mqtt_schalter1 { if (ReadingsVal("mqtt_schalter1","state", "not found") eq "0") { fhem "set B_Dose_Fenster_LED on" } }
ab 00:19 funktioniert es nicht mehr :-(
Zitat
2014.10.13 00:19:44 5: publish received for MyMQTT/60/0/V_TEMP, 26.1
2014.10.13 00:19:44 5: calling readingsSingleUpdate(mqtt_Temperatur1,state,26.1,1
2014.10.13 00:19:44 5: publish received for MyMQTT/60/0/V_TEMP, 26.1
2014.10.13 00:19:44 5: publish received for MyMQTT/60/0/V_TEMP, 26.1
2014.10.13 00:20:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.13 00:20:14 5: SW: c000
2014.10.13 00:20:14 5: MQTT MQTT_MySensors message received: PingResp/at-most-once
2014.10.13 00:21:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.13 00:21:14 5: SW: c000
2014.10.13 00:21:14 5: MQTT MQTT_MySensors message received: PingResp/at-most-once
2014.10.13 00:22:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.13 00:22:14 5: SW: c000
2014.10.13 00:22:14 5: MQTT MQTT_MySensors message received: PingResp/at-most-once
2014.10.13 00:23:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.13 00:23:14 5: SW: c000
2014.10.13 00:23:14 5: MQTT MQTT_MySensors message received: PingResp/at-most-once
2014.10.13 00:24:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.13 00:24:14 5: SW: c000
2014.10.13 00:24:14 5: MQTT MQTT_MySensors message received: PingResp/at-most-once
2014.10.13 00:25:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.13 00:25:14 5: SW: c000
2014.10.13 00:25:14 1: 192.168.100.250:1883 disconnected, waiting to reappear (MQTT_MySensors)
2014.10.13 00:25:14 1: 192.168.100.250:1883 reappeared (MQTT_MySensors)
2014.10.13 00:25:14 5: MQTT MQTT_MySensors message sent: Connect/at-most-once MQIsdp/3/Net::MQTT::Message[3230]
2014.10.13 00:25:14 5: SW: 102600064d51497364700302003c00184e65743a3a4d5154543a3a4d6573736167655b333233305d
2014.10.13 00:25:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.13 00:25:14 5: SW: c000
2014.10.13 00:25:14 5: MQTT MQTT_MySensors message received: ConnAck/at-most-once Connection Accepted
2014.10.13 00:25:14 5: MQTT MQTT_MySensors message sent: Subscribe/at-least-once 9 MyMQTT/71/0/V_LIGHT_LEVEL/at-most-once
2014.10.13 00:25:14 5: SW: 821e000900194d794d5154542f37312f302f565f4c494748545f4c4556454c00
2014.10.13 00:25:14 5: MQTT MQTT_MySensors message sent: Subscribe/at-least-once 10 MyMQTT/60/0/V_TEMP/at-most-once
2014.10.13 00:25:14 5: SW: 8217000a00124d794d5154542f36302f302f565f54454d5000
2014.10.13 00:25:14 5: MQTT MQTT_MySensors message sent: Subscribe/at-least-once 11 MyMQTT/60/1/V_TEMP/at-most-once
2014.10.13 00:25:14 5: SW: 8217000b00124d794d5154542f36302f312f565f54454d5000
2014.10.13 00:25:14 5: MQTT MQTT_MySensors message sent: Subscribe/at-least-once 12 MyMQTT/10/3/V_TRIPPED/at-most-once
2014.10.13 00:25:14 5: SW: 821a000c00154d794d5154542f31302f332f565f5452495050454400
2014.10.13 00:25:14 5: SW: 8a1a000800154d794d5154542f31302f332f565f5452495050454400
2014.10.13 00:25:14 5: SW: 8a17000b00124d794d5154542f36302f312f565f54454d5000
2014.10.13 00:25:14 5: SW: 8a17000a00124d794d5154542f36302f302f565f54454d5000
2014.10.13 00:25:14 5: SW: 8a1e000900194d794d5154542f37312f302f565f4c494748545f4c4556454c00
2014.10.13 00:25:14 5: SW: 8a1a000c00154d794d5154542f31302f332f565f5452495050454400
2014.10.13 00:25:14 5: MQTT MQTT_MySensors message received: PingResp/at-most-once
2014.10.13 00:25:14 5: MQTT MQTT_MySensors message received: SubAck/at-most-once 9/at-most-once
2014.10.13 00:25:14 5: MQTT MQTT_MySensors message received: SubAck/at-most-once 10/at-most-once
2014.10.13 00:25:14 5: MQTT MQTT_MySensors message received: SubAck/at-most-once 11/at-most-once
2014.10.13 00:25:14 5: MQTT MQTT_MySensors message received: SubAck/at-most-once 8/at-most-once
Ich habe 00:25 den Schalter1 ausgelöst und ohne Funktion :-(
Die Temperaturwerte wurden auch nicht mehr aktualisiert
Internals
IODev
MQTT_MySensors
NAME
mqtt_Temperatur1
NR
52
STATE
26.1
TYPE
MQTT_DEVICE
qos
0
retain
0
Readings
state
26.1
2014-10-13 00:19:44
transmission-state
subscription acknowledged
2014-10-13 00:25:14
mqtt_Temperatur1
Attributes
IODev
MQTT_MySensors
deleteattr
room
MQTT-Test
deleteattr
stateFormat
state
deleteattr
subscribeReading_state
MyMQTT/60/0/V_TEMP
deleteattr
verbose 5
deleteattr
und wieder "eingeschalfen" :-(
2014.10.13 00:25:14 5: SW: c000
2014.10.13 00:25:14 5: MQTT MQTT_MySensors message received: ConnAck/at-most-once Connection Accepted
2014.10.13 00:25:14 5: MQTT MQTT_MySensors message sent: Subscribe/at-least-once 9 MyMQTT/71/0/V_LIGHT_LEVEL/at-most-once
2014.10.13 00:25:14 5: SW: 821e000900194d794d5154542f37312f302f565f4c494748545f4c4556454c00
2014.10.13 00:25:14 5: MQTT MQTT_MySensors message sent: Subscribe/at-least-once 10 MyMQTT/60/0/V_TEMP/at-most-once
2014.10.13 00:25:14 5: SW: 8217000a00124d794d5154542f36302f302f565f54454d5000
2014.10.13 00:25:14 5: MQTT MQTT_MySensors message sent: Subscribe/at-least-once 11 MyMQTT/60/1/V_TEMP/at-most-once
2014.10.13 00:25:14 5: SW: 8217000b00124d794d5154542f36302f312f565f54454d5000
2014.10.13 00:25:14 5: MQTT MQTT_MySensors message sent: Subscribe/at-least-once 12 MyMQTT/10/3/V_TRIPPED/at-most-once
2014.10.13 00:25:14 5: SW: 821a000c00154d794d5154542f31302f332f565f5452495050454400
2014.10.13 00:25:14 5: SW: 8a1a000800154d794d5154542f31302f332f565f5452495050454400
2014.10.13 00:25:14 5: SW: 8a17000b00124d794d5154542f36302f312f565f54454d5000
2014.10.13 00:25:14 5: SW: 8a17000a00124d794d5154542f36302f302f565f54454d5000
2014.10.13 00:25:14 5: SW: 8a1e000900194d794d5154542f37312f302f565f4c494748545f4c4556454c00
2014.10.13 00:25:14 5: SW: 8a1a000c00154d794d5154542f31302f332f565f5452495050454400
2014.10.13 00:25:14 5: MQTT MQTT_MySensors message received: PingResp/at-most-once
2014.10.13 00:25:14 5: MQTT MQTT_MySensors message received: SubAck/at-most-once 9/at-most-once
2014.10.13 00:25:14 5: MQTT MQTT_MySensors message received: SubAck/at-most-once 10/at-most-once
2014.10.13 00:25:14 5: MQTT MQTT_MySensors message received: SubAck/at-most-once 11/at-most-once
2014.10.13 00:25:14 5: MQTT MQTT_MySensors message received: SubAck/at-most-once 8/at-most-once
2014.10.13 00:26:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.13 00:26:14 5: SW: c000
2014.10.13 00:27:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.13 00:27:14 5: SW: c000
2014.10.13 00:28:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.13 00:28:14 5: SW: c000
2014.10.13 00:29:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.13 00:29:14 5: SW: c000
2014.10.13 00:30:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.13 00:30:14 5: SW: c000
2014.10.13 00:31:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.13 00:31:14 5: SW: c000
2014.10.13 00:32:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.13 00:32:14 5: SW: c000
2014.10.13 00:33:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.13 00:33:14 5: SW: c000
2014.10.13 00:34:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.13 00:34:14 5: SW: c000
2014.10.13 00:35:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.13 00:35:14 5: SW: c000
2014.10.13 00:36:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.13 00:36:14 5: SW: c000
2014.10.13 00:37:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.13 00:37:14 5: SW: c000
2014.10.13 00:38:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.13 00:38:14 5: SW: c000
2014.10.13 00:39:14 5: MQTT MQTT_MySensors message sent: PingReq/at-most-once
2014.10.13 00:39:14 5: SW: c000
DEF
192.168.100.250:1883
DeviceName
192.168.100.250:1883
FD
4
NAME
MQTT_MySensors
NOTIFYDEV
global
NR
32
NTFY_ORDER
50-MQTT_MySensors
PARTIAL
STATE
opened
TYPE
MQTT
buf
msgid
13
ping_received
0
timeout
60
Readings
connection
timed-out
2014-10-13 00:41:14
@fh555:
Nach den Logs meldet sich die Gegenstelle (192.168.100.250) ja einfach ab (d.h. die Verbindung bricht ab, ist ja kein sauberer Disconnect über das mqtt-protokoll). was läuft denn unter '192.168.100.250'? Ist dass das MySensors MQTT-gateway, oder ein mosquitto-broker?
Während die Gegenstelle abgemeldet ist, kann nichts ankommen. Und nachgeliefert wird das auch nur, wenn der Sensor das mit 'retain' an den Broker senden würde (und der Broker nicht zwischendurch abstürzt)...
Und schau mal nach meinem Beitrag (http://forum.fhem.de/index.php/topic,27725.msg207882.html#msg207882) zu Deinem notify.
Gruß,
Norbert
hallo,
fh555 kann gerade nicht anworten, weil er im Urlaub ist.
Was anderes: ich habe zwei 18B20 parallel auf einer Platine geschaltet, wie spreche ich die mit Fhem an?
Die melden sich im Arduino mit
MyMQTT/21/0/V_TEMP
MyMQTT/21/1/V_TEMP
wenn ich einen
attr mySensorsTemp autoSubscribeReadings MyMQTT/21/+/V_TEMP
mit wildcards mache, findet er nur den ersten Sensor.
Vielen Dank noch für die positiven Bewertungen in meinem Blog-Beitrag.
LG
/robin
Ich hab das grade im Trockenlauf getestet, funktioniert. (In Ermangelung von MySensors-sensoren habe ich die mqtt-messages habe ich mit 'mosquitto_pub -h 192.168.1.4 -t MyMQTT/21/0/V_TEMP -m "wert1"' bzw. 'mosquitto_pub -h 192.168.1.4 -t MyMQTT/21/1/V_TEMP -m "wert2"' geschickt).
Muss also irgendwo außerhalb von fhem liegen. Du kannst mit attr verbose 5 an den MQTT-devices den loglevel so einstellen, dass Du alle von FHEM geschickten und empfangenen Messages detailiert sehen kannst.
Du darfst in Deinem Blog übrigens ruhig konkret angeben, wer die MQTT-module geschrieben hat.
gruß
Hallo,
ich sehe gerade bei den Attributen:
ich dachte wenn ich autoSubscribeReadings mache, werden alles automatisch erkannt.
Muss man dann mit Subscribe Reading trotzdem jeden Sensor nochmal einzeln benennen?
Teste ich heute mal nach. Mosquitto habe ich nicht.
Der Blog-Beitrag ist geändert: http://blog.moneybag.de/fhem-sensoren-an-fhem-mit-nrf24l01-transceiver/
Ist mir gerade noch aufgefallen: Wenn ich einen Doppelklick auf subscribeReading_V_TEMP mache, ändert sich nicht die Dropdown-Box, sodass ich einen Wert in das Text-Feld daneben eingeben kann. Man sagt ja hier, man soll nicht in der config rumspielen.
Wie "erkennt" der Broker, das ein Sensor ausgefallen ist, bzw. ob er ein Signal nicht erhalten hat. Ich habe irgendwo gelesen, da man auch Schaltvorgänge (z.b. Relays) damit machen kann MyMQTT/irgendwas/irgendwie ist ja nur ein Kanal, in dem etwas stattfindet.
LG
/robin
die passenden subscribeReading_xxx-attribute werden beim Eintreffen von Nachrichten anhand des Topics automatisch erzeugt. Sobald alle da sind, kann man das autosubscribeReadings wieder rausnehmen. Funktioniert natürlich nur, wenn der Sensor auch Daten schickt.
Was setzt Du für einen mqtt-broker ein?
das Webinterface unterstützt bisher leider keine Wildcard-attribute ('subscribeReading_.*') und da Attribute pro modul-typ und nicht pro Instanz definiert werden, kann man die konkret gesetzten Attribute auch nicht sinnvoll dynmisch zur Liste der editierbaren (instanzspezifischen) Attribute hinzufügen.
Du kannst das aber als kommando 'attr XXX subscribeReading_V_TEMP MyMQTT/21/0/V_TEMP' einfach oben in der Kommandozeile der Weboberfläche absetzen, dann muss Du die fhem.cfg auch nicht von Hand editieren.
Der Broker kann überhaupt nicht erkennen, ob ein Sensor ausgefallen ist, der bekommt einfach keine Nachrichten mehr vom mqtt-gateway. Der Broker kann nur erkennen, wenn das MySensors mqtt-Gateway ausfällt. Prinzipiell könnte eine Sensorüberwachung im mqtt-gateway realisiert werden, aber wenn ich den Code richtig verstehe macht das auch nix anderes als zwischen Funknachrichten und dem mqtt-broker zu mediieren.
Gruß,
Norbert
Werde ich heute abend mal ausprobieren.
ich nutze das MQTT-Gateway von mySensors und Fhem.
Erfährt denn der Broker wenn ein Signal empfangen / nicht empfangen worden ist? Ich denke da so an einer preiswerten Ersatzlösung von HM.
Hm, hab grade mal einen genaueren Blick in die sourcen des mqtt-gateways geworfen. Das implementiert ja gar keinen mqtt-client, sondern eine (unvollständige) mqtt-broker Schnittstelle. Ich halte das nicht wirklich für schlau, weil das mqtt-Protokoll da eben nur teilweise umgesetzt ist, tatsächliche Subscriptions werden nicht unterstützt, qos feht völlig, der verbundene mqtt-client wird daher keine gesendeten Messages freigeben, wenn qos > 0 verwendet wird. Das wird man auch nur bedingt aufbohren können, weil so ein Arduino ja nur sehr geringe System-resourcen hat. Man könnte nun zwar einen mqtt-broker dazwischensetzen (und eine sogenannte Bridge zum mqtt-gateway konfigurieren), das verlagert das Problem aber nur, weil ja auch da (in der Broker<->Gateway Kommunikation) der Broker davon ausgeht mit einem Broker und nicht einem Client zu kommunizieren. Ist mir schleierhaft, warum hier nicht einfach ein MQTT-client implementiert wurde - der würde mit weniger Resourcen trotzdem Spec-konform arbeiten können. Das man sich so einen separaten mqtt-broker spart ist eigentlich kein richtiges Argument. Mosquitto z.B. ist ziemlich schlank, bei mir braucht der Prozess keine 15MB virtuellen und unter 1MB realen Speicher. Und das Einbinden in eine größere Installation (mit zentralem mqtt-broker und anderen über mqtt angebundenen - nicht MySensors - Sensoren und Aktoren) wird so auch zu einem ziemlichen Gebastel.
Ich will da jetzt nicht über ein fremdes Projekt meckern - das ist schließlich Kost-nix Open-Source und jeder darf gerne was dazu beitragen um es zu verbessern und dem Autor des gateways taugt es wohl auch. (Wenn ich mal Zeit und Lust dafür habe, schreibe ich das mal auf einen mqtt-client um)
Für die MySensors-integration in FHEM über mqtt heißt dass aber auch: Alles was nicht geht, weil das mqtt-gateway nicht spec-konform kommuniziert, werde ich FHEM-seitig ignorieren - da kommen keine spezial MySensors-Workarounds rein, das müsste dann auf der mqtt-gateway seite implementiert werden.
Ich schreib dann mal ein FHEM-modul für das serielle MySensors-Gateway, das Protoll ist ja simpel genug. Das Modul wird dann auch gleich mit dem Ethernet-gateway funktionieren.
Stay tuned.
- Norbert
Hallo Norbert,
ich bin ja schon froh, das der Stein ins Rollen gekommen ist. Ich finde die Technik prima, preiswert und einfach.
Das Gateway von mySensors läuft seit mehreren Tagen stabil. Ich kann natürlich jetzt nicht überblicken, was und wie unterstützt ist. Die Sensoren, die dort mit den diversen Sketchen gezeigt werden, funktioneren die meisten (ich hab nicht alle nachgebaut) auch mit fhem.
Wenn es natürlich noch eine einfachere Methode gibt, vielleicht ohne den Arduino Uno (bei mir), sondern direkt am Raspi, ist das natürlich noch besser. Und wenn dann auch noch an dem korrekten Ablauf des MQTT-Protokoll gearbeitet wird, hat man doch für fhem wieder einen zusätzlichen Kommunikationsstandard hinzubekommen.
Serielles / Lan MQTT-Mysensors - Gateway: Klasse, dann kann man sich aussuchen, wie und wo man das Gateway anschließen kann. Daumen hoch!
Für MySensors würde ich immer einen Arduino als Gateway einsetzen, unabhängig davon, ob der nun über USB (seriell) oder Ethernet angebunden ist. Einfach, weil diese Schnittstellen auf praktisch jedem System vorhanden sind (und weil der code für diese Gateways schon existiert). Man könnte zwar grundsätzlch so ein nRF24L01-modul auch direkt über SPI an einem Raspberry Pi anschließen - es ist aber nicht trivial darauf ein portables plattformunabhängiges FHEM-modul aufsetzen zu lassen (das dann auch auf anderen Rechnern läuft), da müsste man erst mal einen Abstraktionslayer für SPI (analog zu den I2C-modulen) dazwischenschieben.
Die Protokoll-implementierung des MQTT-moduls ist aus meiner Sicht vollständig, da kann man sich jetzt eigentlich nur noch Features (wie z.B. das Bridgen von Attribute-werten nach mqtt-topics) dazuwünschen. Für MySensors solltest Du halt darauf achten, dass das Attribut 'qos' auf '0' steht, sonst gibt das Modul den Speicher für ausgehende Messages (MySensors-aktoren) nicht wieder frei.
Gruß,
Norbert
Das meine ich ja.
Arduino.Gateway / über Lan / oder über USB.
Wenn der Benutzer entscheiden könnte, wie er es haben möchte, umso besser.
robin
Habe jetzt die Hardware bekommen und etwas damit rumgespielt.
Die Reichweite ist wirklich überraschend gut. Muss ich etwas genauer testen.
Das Protokoll ist schon recht gesprächig.
Zuerst will der Sensor eine eindeutige ID zugewiesen bekommen, dann ob er metrisch oder imperial messen soll. Wenn er das alles hat, dann kommen Sketch-Name, -Version, vorhandenen Sensoren und eben die Werte.
Ich habe auf die Schnelle aus dem Norberts Modul eine erste Testversion für den Serial-Sketch erstellt. Die grundsätzliche Kommunikation funktioniert, Meldungen werden empfangen und können auch gesendet werden. Ein neuer Sensor bekommt seine ID...
Jetzt fehlt eine Menge Fleißarbeit zum Auswerten von allem möglichen Message- und Sensor-Typen. Vieleicht poste ich morgen eine erste testbare Version...
2014.10.17 01:00:55.692 3: Parse message: 0;0;3;0;9;read: 1-1-0 s=255,c=0,t=17,pt=0,l=3:1.4
2014.10.17 01:00:55.694 3: MySensors: Gateway says: read: 1-1-0 s=255,c=0,t=17,pt=0,l=3:1.4
2014.10.17 01:00:55.696 3: Parse message: 1;255;0;0;17;1.4 <= Protokol 1.4
2014.10.17 01:00:55.699 3: MS_DEV: parse RAW message: MS 1;255;0;0;17;1.4 IODev: mysensors
2014.10.17 01:00:55.701 3: Parse message: 0;0;3;0;9;read: 1-1-0 s=255,c=3,t=6,pt=1,l=1:0
2014.10.17 01:00:55.704 3: MySensors: Gateway says: read: 1-1-0 s=255,c=3,t=6,pt=1,l=1:0
2014.10.17 01:00:55.705 3: Parse message: 1;255;3;0;6;0 <= Imperial oder Numeric?
2014.10.17 01:00:57.436 3: Parse message: 0;0;3;0;9;read: 1-1-0 s=255,c=3,t=11,pt=0,l=8:Humidity
2014.10.17 01:00:57.438 3: MySensors: Gateway says: read: 1-1-0 s=255,c=3,t=11,pt=0,l=8:Humidity
2014.10.17 01:00:57.440 3: Parse message: 1;255;3;0;11;Humidity <= Sketch: Humidity
2014.10.17 01:00:57.441 3: Parse message: 0;0;3;0;9;read: 1-1-0 s=255,c=3,t=12,pt=0,l=3:1.0
2014.10.17 01:00:57.443 3: MySensors: Gateway says: read: 1-1-0 s=255,c=3,t=12,pt=0,l=3:1.0
2014.10.17 01:00:57.444 3: Parse message: 1;255;3;0;12;1.0 <= Sketch Verion 1.0
2014.10.17 01:00:57.446 3: Parse message: 0;0;3;0;9;read: 1-1-0 s=0,c=0,t=7,pt=0,l=3:1.4
2014.10.17 01:00:57.447 3: MySensors: Gateway says: read: 1-1-0 s=0,c=0,t=7,pt=0,l=3:1.4
2014.10.17 01:00:57.449 3: Parse message: 1;0;0;0;7;1.4 <= Sensor 0 ist ein Humidity-Sensor
2014.10.17 01:00:57.451 3: MS_DEV: parse RAW message: MS 1;0;0;0;7;1.4 IODev: mysensors
2014.10.17 01:00:57.453 3: Parse message: 0;0;3;0;9;read: 1-1-0 s=1,c=0,t=6,pt=0,l=3:1.4
2014.10.17 01:00:57.454 3: MySensors: Gateway says: read: 1-1-0 s=1,c=0,t=6,pt=0,l=3:1.4
2014.10.17 01:00:57.636 3: Parse message: 1;1;0;0;6;1.4 <= Sensor 1 ist ein Temeratur-Sensor
2014.10.17 01:00:57.637 3: MS_DEV: parse RAW message: MS 1;1;0;0;6;1.4 IODev: mysensors
2014.10.17 01:00:58.681 3: Parse message: 0;0;3;0;9;read: 1-1-0 s=1,c=1,t=0,pt=7,l=5:24.0
2014.10.17 01:00:58.688 3: MySensors: Gateway says: read: 1-1-0 s=1,c=1,t=0,pt=7,l=5:24.0
2014.10.17 01:00:58.689 3: Parse message: 1;1;1;0;0;24.0 <= 24°C
2014.10.17 01:00:58.690 3: MS_DEV: parse RAW message: MS 1;1;1;0;0;24.0 IODev: mysensors
2014.10.17 01:00:58.691 3: Parse message: 0;0;3;0;9;read: 1-1-0 s=0,c=1,t=1,pt=7,l=5:38.0
2014.10.17 01:00:58.692 3: MySensors: Gateway says: read: 1-1-0 s=0,c=1,t=1,pt=7,l=5:38.0
2014.10.17 01:00:58.693 3: Parse message: 1;0;1;0;1;38.0 <= 38 % rH (der DHT11 ist der grösste Schrott)
2014.10.17 01:00:58.695 3: MS_DEV: parse RAW message: MS 1;0;1;0;1;38.0 IODev: mysensors
Hallo Alexander,
ich habe auch schon was geschrieben, aber in Ermangelung von Hardware noch nicht real testen können:
00_MYSENSORS (https://github.com/ntruchsess/fhem-mirror/raw/mysensors_unified/fhem/FHEM/00_MYSENSORS.pm)
10_MYSENSORS_DEVICE.pm (https://github.com/ntruchsess/fhem-mirror/raw/mysensors_unified/fhem/FHEM/10_MYSENSORS_DEVICE.pm)
lib/Device/Constants.pm (https://github.com/ntruchsess/fhem-mirror/raw/mysensors_unified/fhem/FHEM/lib/Device/MySensors/Constants.pm)
lib/Device/MySensors/Message.pm (https://github.com/ntruchsess/fhem-mirror/raw/mysensors_unified/fhem/FHEM/lib/Device/MySensors/Message.pm)
(oder einfach den mysensors_unified-branch (https://github.com/ntruchsess/fhem-mirror/tree/mysensors_unified) aus meinem fhem-mirror auschecken:
git clone https://github.com/ntruchsess/fhem-mirror.git
git checkout mysensors_unified
Da sind schon alle Konstanten für das Protokoll drin, S_GET und S_SET werden auf das (generische) Node-modul umgeleitet. Werte empfangen (S_SET-messages) setzen dynamisch benannte readings, autocreate neuer MYSENSORS_DEVICE-instanzen wenn Presentation-messages eingehen etc... Was noch fehlt ist die Behandlung der ganzen Internal-messages, das ist halt nur im Gateway-sourcecode dokumentiert und selbiges läuft ohne nRF24L01-modul (sollten die Tage mit der Post kommen) nur bis zur ersten Fehlermeldung 'check wires'...
Wäre prima, wenn wir die Aktivitäten bündeln könnten.
Gruß,
Norbert
EDIT 20.10.2014, 19:50 Uhr: Links und Text an den mysensors_unified-branch angepasst
so, die bestellten nRF24L01 sind vorhin gekommen, hab grade das SerialGateway und einen BinarySwitchSensor zusammengestöpselt.
das MYSENSORS-modul redet auch schon brav mit dem Gateway ;-) und versteht schon mal die wichtigsten internal-Messages, den Inclusion-mode kann man vom Modul an und abstellen. Allerdings kommt vom Sensor am Gateway nix an (der Sensor loggt nur immer 'req node id
send: 255-255-255-0 s=255,c=3,t=3,pt=0,l=0,st=fail:' auf seine Serielle Schnittstelle) :-(
(der code im Git ist aktualisiert, urls haben sich dadurch nicht geändert).
Gruß,
Norbert
Hallo Norbert,
der Sensor ist bestimmt in Ordnung, aber bevor er etwas sinnvolles sendet, will er erstmal eine eindeutige ID bekommen.
Das will er mit 'req node id' mitteilen. War bei mir allerdings etwas anders: 255,255,0,3,0 oder so. Das muss dann mit 255,255,0,4,<ID> beantwortet werden.
Das muss der Controller, also FHEM-Modul tun. Danach fragt er noch nach Metric/Imperial (muss aber nicht unbedingt beantwortet werden) und dann kommen Konfig-Daten (presentation etc.) und auch Werte.
Da der Controller sich die ID merkt (EEPROM) ist das beim Testen etwas blöd. Ich überlge schon, mir ein extra Sketch zu bauen, der genau das nicht macht.
Ich habe mir Deinen Code kurz angesehen. Da kann ich wohl noch einiges an Perl lernen. ;) Da Dein Code IMHO schöner ist, werde ich meine Module verwerfen. Ich würde aber gerne da mitarbeiten. Wo könnte ich Dich unterstützen?
Wenn ich beim kurzen Blick richtig verstanden habe, werden Readings wie Konstanten benannt
use constant variableTypes => qw{ V_TEMP V_HUM V_LIGHT V_DIMMER V_PRESSURE V_FORECAST V_RAIN
V_RAINRATE V_WIND V_GUST V_DIRECTION V_UV V_WEIGHT V_DISTANCE
V_IMPEDANCE V_ARMED V_TRIPPED V_WATT V_KWH V_SCENE_ON V_SCENE_OFF
V_HEATER V_HEATER_SW V_LIGHT_LEVEL V_VAR1 V_VAR2 V_VAR3 V_VAR4 V_VAR5
V_UP V_DOWN V_STOP V_IR_SEND V_IR_RECEIVE V_FLOW V_VOLUME V_LOCK_STATUS };
sub variableTypeToStr($) {
(variableTypes)[shift];
}
Finde ich nicht so glücklich. Wollen wir diese auf menschenlesbaren Namen wie 'temperature' mappen? Am besten mit einer Möglichkeit, per Attribut-Definition umzubenennen (für die Custom-Messages)?
Grüße,
Alexander
Architektur-Fragen:
Ich sehe das Modul MYSENSORS als eine Implementierung des Controllers, der alles delegiert und steuert. NODE ist für die Verarbeitung der Nachrichten von und zu einzelnen Nodes Zuständig. Wozu ist dann SENSOR? Sollen alle Readings in einzelnen Module aufgeteilt werden? Ich finde es besser, die Readings einer Node zusammen in einem Device zu fassen.
Die Verarbeitung der Internal-Messages läuft bei Dir im NODE. Wäre das nicht besser im MYSENSORS (also Controller) aufgehoben?
Nutzt Du den Dispatch-Mechanismus gar nicht und rufst einfach entsprechende Methode von den Device-Modulen weiter? Hat das einen bestimmten Zweck?
Möglicherweise sind das doofe Fragen ;) Ich hatte noch nicht die Zeit, den Code ganz genau zu lesen.
Grüße,
Alexander
Hab grade den sensor-sketch auf einen Nano geflasht, schon kommen die Nachrichten beim Gateway an... (War vorher auf einem Mega - irgendwie scheint MySensors wohl nicht mit der unterschiedlichen Pinbelegung des SPI-interfaces beim Mega klarzukommen).
Also:
Die Konstanten heißen so, wie in der MySensors-API weil ich 'Device::MySensors' gegebenenfalls als eigene Library (FHEM-unabhängig) veröffendlichen werde. Die sollen auch nicht zwingend zur Anzeige kommen, das ist eher für's logging, oder wenn man eben noch kein Mapping auf 'lesbare' Readings implementiert hat.
Die Trennung in Node und Sensor-modul mache ich, weil an einem Node auch mehrere gleichartige Sensoren dranhängen können. Das über die Reading-namen zu unterscheiden wie es div. GPIO-module tun halte ich für eher unglücklich, da muss man dann fast zwingend noch einen Readingsproxy dazu konfigurieren, wenn man etwas direkt aus dem GUI-heraus (á la 'on/off') schaltbar machen will.
Das Node-modul verwaltet dann die gemeinsame Config (und meldet z.B. den Batteriestand etc), die Sensor-module enthalten nur die Sensor-spezifischen Readings/Sets.
Das zentrale Mysensors-modul verarbeitet die Internal-messages, die vom Gateway kommen. Internal-messages der Nodes werden vom zentralen Modul an die Node-module weiterdeligiert.
Der Dispatch-mechanismus ist mir irgendwie zu ineffektiv für so eng gekoppelte Module. Da wird ja grundsätzlich alles serialisiert/deserialisiert, auch wenn die kommunizierenden Module in der gleichen FHEM-instanz laufen (was ja eher die Regel, als die Ausnahme ist). Das gehört mal grundlegend dahingehend überarbeitet, dass das serialisieren/deserialisieren transparent (und nur bei remote Aufrufen) erfolgt) und man richtige Objekte übergeben kann. Ist aber eine andere Baustelle.
Wie du unterstützen könntest? Schau einfach in den Code rein und mach Vorschläge, wo Du meinst was machen zu wollen oder zu können. Mach Dir einfach einen clone des fhem-mirrors auf Github und schick mir pull-requests gegen den 'mysensors'-branch.
Gruß,
Norbert
Verstehe, danke für die Erklärungen.
Ich würde zwar besser finden, wenn die Sensoren alle Readings beisamen haben, ansonsten explodiert die Zahl der 'Geräte', allein DHT-Sensoren liefern immer Feuchte und Temperatur gleichzeitig. aber gut...
Ich werde mir heute später alles genauer ansehen.
LG,
Alexander
so, I_ID_REQUEST/RESPONSE ist implementiert (https://github.com/ntruchsess/fhem-mirror/commit/4db23b70343dc2d13ea87aa3e84c30eb79736712?diff=unified#diff-0da889d02d76d530793a4d207ed29011R316).
Schon schick das Ganze - der BinarySwitchSensor schickt ja unmittelbar bei Zustandsänderung und im FHEM kommt es gefühlt verzögerungsfrei an :-)
Gruß,
Norbert
das Modul 'MYSENSORS_SENSOR' hat jetzt ein Attribut 'setCommands' mit dem man dynamisch Werte für 'set' definieren kann:
attr MY_LIGHT_47_11 setCommands on:V_LIGHT:0 off:V_LIGHT:1
damit kann man 'set MY_LIGHT_47_11 on' und 'set MY_LIGHT_47_11 off' aufrufen.
alternativ:
attr MY_LIGHT_47_11_set_V_LIGHT 0 1
erlaubt: 'set MY_LIGHT_47_11 V_LIGHT 0' bzw. 'set MY_LIGHT_47_11 V_LIGHT 1'
- Norbert
Hallo Alexander,
ich habe grade noch Default-attributewerte für per autocreate angelegte Devices (https://github.com/ntruchsess/fhem-mirror/commit/393566c911406435cd3ac52433122332a7e5b9e2#diff-0da889d02d76d530793a4d207ed29011R95) eingeführt.
Zitat von: hexenmeister am 17 Oktober 2014, 13:19:36Ich würde aber gerne da mitarbeiten. Wo könnte ich Dich unterstützen?
Eine große Hilfe wäre für die einzelnen Sensor-typen sinnvolle defaults zu ermitteln und da einzupflegen...
Hast Du eine Ahnung, welche Semantik beim Acknowledge-flag erwartet wird (das ignoriere ich bisher völlig)?
Und bei den Internal-messages gibt es auch noch einige weiße Flecken auf der Landkarte, bei denen ich nichts dokumentiertes drüber finde...
Was hat es eigentlich mit dem 'inclusion-mode' des Gateways auf sich? Ich hab das per 'set inclusion-mode on/off' schaltbar gemacht, aber was bewirkt das eigentlich? Ich hab im Verhalten des Gateways keinen Unterschied feststellen können...
soll ich das Gateway-reading 'log-message' für die Log-messages eigentlich drin lassen, oder reicht es da einfach mit Loglevel 4 ins Log zu schreiben?
Und zu guter letzt: soll ich die Module noch mal umbenennen? z.B. MYS_GW für das Gateway, MYS_NODE und MYS_DEVICE für die beiden anderen? Habt Ihr bessere Vorschläge?
Gruß,
Norbert
Hi Norbert,
Du warst ja schon richtig fleißig ;)
Ich habe jetzt etwas Zeit, will mir das alles ansehen. Mit den Default werde ich mir Gedanken mache, bei der Gelegenheit würde ich gerne noch den Readings 'richtige' namen geben. Am besten auch in Form von Default, Idealerweise per Attribut überschreibbar. Was hälst Du davon, gleich auch Maßeinheiten mit aufzunehmen? Ich würde sogar immer nur metrisches System lassen, oder kann jemand Imperial brauchen?
Ack habe ich mir noch nicht wirklich angesehen. Ich denke, man kann das frei handhaben, wird es angefordert, wird es beantwortet. Für Aktoren, denke ich, wäre Ack angebracht. Sensoren wollen auch ein haben. Scheint so, dass bis auch einige Service-Befehle ACK überall gewünscht wird.
Include war für mich auch ein Rätsel. Im Sketch habe ich (zugegeben auf die Schnelle) auch nichts sinnvollen gefunden. Ich denke, das ist ein Signal an Controller (also in unserem Fall FHEM), neue Sensoren zuzulassen. Man kann ja am Gateway per taster starten. Mach auch Sinn, da ansonsten bekommt ein 'jungfreulicher' Sensor beim ersten Test gleich eine ID, die man nicht ohne weiteres wieder ändern kann.
Bei Log-Messages habe ich gestern auch zunächst gedacht, dass da was sinnvolles zu loggen wäre. Dafür ist der Gateway aber zu gesprächig mit seinen Logs. Steht auch unwichtiges Zeug drinn. Ich würde die auf Level 5 loggen.
Ob man die Module umbenennen soll, bin ich mir auch nicht sicher, ich hatte gerstern meine MS_LINK und MS_DEV genannt. MYS klingt auch iwi nicht sonderlich gut. Ich würde so lassen, MYSENSORS, MYSENSORS_NODE und MYSENSORS_DEVICE klingen doch ganz gut.
Grüße,
Alexander
So, installiert und läuft erstmal.
Mein Perl ist pingeliger als deiner. Ich musste in 00_MYSENSORS Zeile 241 um 3. Parameter erweitern: DevIo_SimpleWrite($hash,"$txt\n", undef);
Nach dem ich autocreate eingeschaltet habe (dies könnte man durch den Inclusion-Taster automatisch tun) wurden zu meinem Humidity-Sensor 3 Devices erstellt:
MY_ARDUINO_NODE_1_255
MY_HUM_1_0
MY_TEMP_1_1
Nach meinem Geschmack etwas zu viel. Vor allem Arduino-Node ist eigentlich zu nichts zu gebrauchen. Sogar darin enthaltenes Attribut "coonfig" scheint nicht zu funktionieren. Dort steht zwar M, Temp.Sensor liefert jdoch 75. Wird Fahrenheit sein.
Ich bin da offen für Vorschläge, wo man die Funktionalität des Arduino_node (batterylevel, config, ggf. time) sinnvoll unterbringt. Das mit dem 'config'-attribut ist natürlich etwas dämlich, liegt dann aber wohl am Sketch. Wenn Du verbose auf 5 setzt, kannst Du sehen, ob die entsprechende I_CONFIG-message raus geht.
Ich hab noch mal nach dem Inclusion-mode geschaut. Der scheint im MyGateway.cpp wirklich nix anderes zu machen als den Blink-modus zu verändern, damit könnte man den Autocreate-modus anzeigen. Dumm nur, dass der Sketch das selbsttätig wieder zurücksetzt.
- Norbert
Lustigerweise hatte ich gestern mit meinen Modulen korrekte Temperatur anzeige. Dabei hatte ich die Config Message für Metric gar nicht implementiert. Ich muss mal in den Sketch gucken.
Ich finde es gar nicht so schlecht, dass IncludeModus automatisch zurückgesetzt wird. Es dürfte so gemeint sein: Man drückt auf di Taste und hat x-Minuten Zeit einen neuen Sensor anzumachen. Dieser wird registriert und Include-Modus beendet. Da dabei entsprechende Messagen an Controller rausgehen, können wir sauber darauf reagieren. Und autocreate-Attribut kann z.B. parallel dazu genutzt werden, diesen Modul daurhaft einzuschalten.
Was spricht dagegen, alle Readings und Steuerungen eines Hardware-Devices, wie bei meisten anderen Systemen auch nur in einer SoftwareModul-Instanz zusammenzufassen? Ich stelle mir nur eine Flut von FHEM-Devices, wenn ich in jedem Zimmer so ein Temp/Hum/Light-Sensor installiere ;)
wg. inclusion-mode: habe ich gerade mit 'autocreate'-attribut funktionell zusammengelegt (und ins git committed). Bei aktiviertem 'inclusion-mode' werden Devices automatisch angelegt, wenn Presentation-messages eintreffen. Ist autocreate gesetzt, wird 'inclusion-mode' im Gateway aktiv gehalten. Ist 'autocreate' nicht gesetzt, kann man den 'inclusion-mode' vom Gateway aus oder per set-commando aktivieren (setzt sich bei nicht gesetztem 'autocreate' nach 1 Minute von selber wieder zurück).
Wg. Zusammenlegen 'Node' und 'Device': dagegen spricht, dass man dann in einem Device viele, ggf. equivalente Readings hat. Also wenn man z.B. einen Sketch für eine Relays-karte macht kann man die Relays nicht mehr (ohne Readingsproxy) einfach auf der Weboberfläche ein-/aus-schalten. Die Readingproxies könnte man aber natürlich optional automatisch mit dazu anlegen (damit könnte ich mich auch anfreunden...)
Gruß,
Norbert
Mit Inclusion klingt sauber.
Den Einwand wg. Einzeldevices verstehe ich. Beide Wege bringen Nachteile mit sich. Ich denke noch darüber nach. Ein Argument wäre natürlich gleiches Verhalten mit den Anderen Geräten in FHEM...
Mit dem Metric/Imperial funktioniert nachweislich nicht. Wenn ich das in EEPROM wieder auf FF setze und das Überschreiben unterdrücke (das ist dann egal, ob im Sketch oder durch das Unterdrücken von Ausgehenden Message aus dem Modul), dann läufts korrekt. Wenn ein Message von Controller mit 'M' eintrifft, dann geht das System von Imperial aus. Message wird nicht wie gewünscht interpretiert. Das passiert weil Payload-Typ nicht als Byte erkannt wird. Die Methode getByte liefert dann 0 und isMetric = msg.getByte() == 'M' funktioniert natürlich nicht wie gewünscht. Ich versuche zu verstehen, wie PayloadType gesetzt wird.
Folgendes habe ich gefunden:
uint8_t command_ack_payload;
// 3 bit - Command type
// 1 bit - Request an ack - Indicator that receiver should send an ack back.
// 1 bit - Is ack messsage - Indicator that this is the actual ack message.
// 3 bit - Payload data type
und
typedef enum {
P_STRING, P_BYTE, P_INT16, P_UINT16, P_LONG32, P_ULONG32, P_CUSTOM, P_FLOAT32
} payload;
Ich glaube mittlerweile, dass Gateway ein Fehler hat. Scheinbar nimmt dieser immer Typ P_STRING an, wenn etwas as der Seriellen Schnittstelle kommt. Methode parseAndSend in MyGateway.cpp macht msg.set(value); und value ist als char *value=NULL; definiert. Dann wind eben MyMessage& MyMessage::set(const char* value) aus MyMessage.cpp aufgerufen und da wird PayloadType P_STRING gesetzt. Kannst Du vielleicht bei Gelegenheit auch mal drauf schauen? Wenn sich meine Vermutung bestätigt, melden wir das Problem an den MySynsors-Entwickler weiter.
Bis dahin funktionier Metric nur, wenn man I_CONFIG Message nicht beantwortet.
So, heute fallen mir schon die Augen zu... So viel Zeit mit dem blöden Metric/Imperial verbracht. >:(
Habe für Imperial/Metric-Problem eine (aus meiner Sicht einfache) Lösung implementiert und in MySensors-Forum vorgeschlagen: http://forum.mysensors.org/topic/334/issue-with-temperature-units/19
EDIT:
Es kam schon eine Antwort. Dieser Fehler ist bereits bekannt und korrigiert. Allerdings gibt es in seinem GitHub die Library an zwei Stellen. Eine aktuell, eine nicht. Ich habe natürlich die falsche genommen...
Habe jetzt Unterstützung zum Umbenennen der (technischen) Readings implementiert, angefangen Gedanken über die Default-Attribute zu machen und Constants upgedatet.
Leider kenne ich mich mit dem GIT nicht so gut aus. Habe auf die Schnelle kein pull request hinbekommen (TortoiseGit und ich haben uns wohl gegenseitig nicht verstanden) :(
Daher sind hier die Patches.
EDIT:
Git-Commando-Zeile lieferte folgendes:
The following changes since commit 4d2385910c1ed48b9ca2b823b0b58b574192dd07:
Merge branch 'mysensors' of https://github.com/ntruchsess/fhem-mirror into mysensors (2014-10-19 01:11:35 +0200)
are available in the git repository at:
https://github.com/hexenmeister/MyFHEM.git mysensors
for you to fetch changes up to 4d2385910c1ed48b9ca2b823b0b58b574192dd07:
Merge branch 'mysensors' of https://github.com/ntruchsess/fhem-mirror into mysensors (2014-10-19 01:11:35 +0200)
Kannst Du damit was anfangen?
danke für die Patches. Ich bin leider erst gerade eben dazu gekommen reinzuschauen (musste gestern und Heute was an meiner Baustelle machen, nächste Woche wäre die Nachttemperaturen wohl schon zu tief).
Das mit dem Pull-request geht so: Du musst das Repository auf Github selbst clonen und dann Deine Änderungen in Dein geclontes Repository pushen. Der Pull-request wird dann auf Github selbst erstellt und hat mit Deinem lokalen Repository nichts mehr zu tun.
Ich hab Deine Patches gerade mal händig eingespielt. Damit Du das mit dem Pull-request besser verstehst hab ich Deine Änderungen bei mir in den 'mysensors_alex'-branch gepusht und dazu einen Pull-request gegen den 'mysensors'-branch erstellt (https://github.com/ntruchsess/fhem-mirror/pull/15/files). Das schöne daran ist, dass man in dem Pull-request alle Differenzen sieht und jede Zeile kommentieren kann (sozusagen 'am lebenden Objekt...')
Das Attributgesteuerte Mappen der Readings könnte man eigentlich doch auch mit UserReadings machen? Dann bräuchte man gar keinen eigenen Code im Modul, es würden die passenden Default-Attribute reichen.
Gruß,
Norbert
Theoretisch habe ich des mit dem PullRequest (glaube ich) verstanden ;) Werde mir heute abend genauer ansehen.
Über UserReadings habe ich auch schon nachgedacht, bin aber zu der Meinung gekommen, dass das nicht das gleiche ist. Damit kann man die bestehenden Readings kopieren. Ich wollte diese jedoch ersetzen. Ich denke, das ist im Interesse der Benutzer, dass die Benennung mit anderen Modulen homogen ist. Nach Möglichkeit sollten sie auch menschenlesbar sein. Die derzeitigen Namen sind mir zu technisch, daher würde ich die am liebsten ganz ausblenden können, unter andern damit sie auch nicht im Log landen (klar, kann man verhindern, aber das ist wieder Zusatzaufwand). Da befand ich die Lösung mit dem 'Ummappen' für ein gangbaren Kompromis.
Grüße,
Alexander
Wenn die technischen Namen ganz verschwinden sollen, dann muss man das Mapping auch im Code festlegen, sonst taucht es im Attribut ja doch wieder auf ;-)
Bevor ich mich dessen annehme habe ich aber erst mal noch genug Arbeit damit MYSENSORS_NODE und MYSENSORS_SENSOR in ein einziges Device MYSENSORS_DEVICE zusammenzuführen.
Gruß,
Norbert
Zitat von: ntruchsess am 20 Oktober 2014, 12:36:03
sonst taucht es im Attribut ja doch wieder auf
... was für die Custom-Werte bei MySensors wohl der einzige Wert sein wird, einen sinvollen Namen zu vergeben...
für die Custom-variablen (V_VAR1 ff) hast Du natürlich recht, die kann man nicht hardcoded mappen. Muss ich mir noch mal genauer durch den Kopf gehen lassen, wie man das einerseits flexibel, andererseits nicht unnötig kompliziert bzw. mit unnötig vielen Attributen macht.
Ich hab jedenfalls erst mal MYSENSORS_NODE und MYSENSORS_SENSORS in MYSENSORS_DEVICE zusammengefasst (https://github.com/ntruchsess/fhem-mirror/commit/18f319840e4d37dc8345b0651f41fb1ce6e4019b). Funktioniert vom Grundsatz her schon mal, Ist aber nicht ganz so weit, wie die vorherige Lösung (das Autocreate beschränkt sich auf das Anlegen des Devices ohne weitere Konfiguration für die representierten Sensoren/Aktoren - die dafür vorgesehene Methode onPresentationMessage (https://github.com/ntruchsess/fhem-mirror/blob/mysensors_unified/fhem/FHEM/10_MYSENSORS_DEVICE.pm#L169) ist aktuell noch leer). Code im branch mysensors_unified (https://github.com/ntruchsess/fhem-mirror/tree/mysensors_unified/):
00_MYSENSORS.pm (https://github.com/ntruchsess/fhem-mirror/raw/mysensors_unified/fhem/FHEM/00_MYSENSORS.pm)
10_MYSENSORS_DEVICE.pm (https://github.com/ntruchsess/fhem-mirror/raw/mysensors_unified/fhem/FHEM/10_MYSENSORS_DEVICE.pm)
die anderen Dateien (lib/Device/MySensors/...) unverändert...
als Beispiel mal eine Konfiguration für den RelayWithButtonActuator.ino, die den Zustand bidirektional auf die STATE-werte 'on/off' abbildet (damit kann man den Aktuator sowohl aus der Weboberfläche heraus direkt schalten, als auch die sensorseitige Zustandsänderung (Schalten per Button am Arduino) direkt auf der Oberfläche visualisiert bekommen):
define gateway MYSENSORS /dev/ttyUSB0@115200
attr gateway stateFormat connection
define node MYSENSORS_DEVICE 245
attr node IODev gateway
attr node setCommands on:LIGHT_1:1 off:LIGHT_1:0
attr node stateFormat {ReadingsVal("node","LIGHT_1",0) ? "on" : "off"}
Das mit dem Mapping habe ich da noch nicht reingearbeitet, erst muss die Basis 'rund' laufen ;-)
Gruß,
Norbert
Handling von Acknowlege ist implementiert (https://github.com/ntruchsess/fhem-mirror/commit/8423ef24af8c384f0dc48eca1b224c7b11f0cb37). Das 'MYSENSORS'-device hat dafür das Attribut 'requestAck' bekommen.
Wenn dieses gesetzt ist, dann werden beim Ausführen von 'set XXX'-befehlen die Readings der MYSENSOR_DEVICE-nodes erst dann aktualisiert, wenn das zugehörige Acknowlege eintrifft. Ist das Attribut nicht gesetzt, geschieht dies sofort (schon beim Absenden der C_SET-message).
- Norbert
Die neue Version gefällt mir sehr gut. Ich musste zwei Kleinigkeiten ändern, damit sie bei mir problemlos läuft. Dafür habe ich Dir testweise ein Pull-Request geschickt (https://github.com/ntruchsess/fhem-mirror/pull/16). Ich denke, ich weiß jetzt wie es geht (sehr einfach :) ).
Zitatfür die Custom-variablen (V_VAR1 ff) hast Du natürlich recht, die kann man nicht hardcoded mappen. Muss ich mir noch mal genauer durch den Kopf gehen lassen, wie man das einerseits flexibel, andererseits nicht unnötig kompliziert bzw. mit unnötig vielen Attributen macht.
Wir können doch beides machen. MappingAttribute erlauben die Readings generell zu umbenennen, was für di Customs von User auch gemacht werden soll. Für die bekannten können wir intern die selbe Map füllen, die auch von den Map-Attributen gepflegt wird. Somit wird der Benutzen nicht mit vielen Atributen behelligt.
Grüße,
Alexander
Zitat von: hexenmeister am 20 Oktober 2014, 21:42:05sehr einfach :)
gell, kaum macht man's richtig, schon geht's -> Danke Dir. :-)
ja, das mit dem Mapping stelle ich mir auch so in der Art vor. Das mit dem Acknowledge braucht wohl noch intensieves Testen (der Retransmit-mechanismus ist noch recht rudimentär, da braucht es noch eine Logik, die die zeitlichen Abstände größer werden läßt und nach einem Timeout das Device auf 'not available' setzt).
Gruß,
Norbert
ZitatDas mit dem Acknowledge braucht wohl noch intensieves Testen
Das bezieht sich auf Aktors und für Sensoren nicht relevant, richtig? Müsste man mit einem Relay-Skatch testen können, indem man ihn für verschiedene kurze Zeiträume abschaltet?
EDIT: ich habe noch ein Transmitter-Board, kann mir morgen ein Relay-Aktor bauen, dann habe ich sowohl Sensor als auch ein Aktor zum Testen.
im Augenblick schickt das MYSENSORS-modul alle message mit gesetztem requestAck-flag. Um Re-transmits zu vermeiden muss man jetzt noch strukturiert ermitteln, welche Messages von der MySensors.cpp sowieso nicht acknowledged werden.
Gruß,
Norbert
Habe ein Vorschlag für die Implementierung von Readings-Remapping geschickt. Was mir da nicht gefällt, ist die ID-Nummer des Sensors. Habe aber erstmal drin gelassen, da ein Node anscheinend mehrere gleiche Sensoren haben kann. Muss man noch darüber nachdenken. Eine Möglichkeit wäre ein Readings 'temperatur' zu nennen, wenn es nur einen "TEMP"-Wert gesendet wird und Nummer verwenden, wenn es mehrere existieren.
Ich habe mich schon ein wenig in MySensors.cpp umgesehen. Morgen werde mal ich nach den Ack-Verhalten sehen.
ja, ein Node kann natürlich mehrere gleichartige Sensoren haben. Wenn man das dynamisch machen wollte (indem man nur den Typ des Readings mapped), hat man hier natürlich die Schwierigkeit, dass man das beim Auswerten der Attribute nicht wissen kann, welche und wie viele childIds der Sensor wirklich hat. (Das weis man eventuell beim Eintreffen der ersten C_SET-messages auch noch nicht - man kann die Presentation-messages nach meinem Verständnis ja nicht geziehlt abfragen - mein Versuch mit der I_REBOOT-message war wenig erfolgreich (ein Arduino mit Standard-bootloader geht da in einen nur durch Trennen von der Stromversorgung abbrechbaren Boot-loop). Bleibt eigentlich nur, als AttributeWert die childId explizit mit aufzunehmen. Dann läßt sich das bisherige Reading beim Anlegen oder Löschen des Mappings sauber aufräumen bzw. in das neue Reading überführen.
Die statischen Mappings müssten nach der Logik fast schon zwingend die childId übernehmen.
Also:
attr <node> map_TEMP_1 temperature
bzw.
attr <node> map_TEMP_1 temperature1
attr <node> map_TEMP_2 temperature2
automatisch gemappt wäre es immer:
TEMP_X -> temperatureX
Gruß,
Norbert
Zitatein Arduino mit Standard-bootloader
Bei MySensors scheint ein eigenes Bootloader zu geben, wenn ich richtig sehe, sogar mit OTA Möglichkeit. Habe mir aber noch nicht näher angesehen.
Deine Beschreibung fürs Mapping schein mir ein sauber gangbarer Weg zu sein.
ZitatDann läßt sich das bisherige Reading beim Anlegen oder Löschen des Mappings sauber aufräumen bzw. in das neue Reading überführen.
Danke nicht, dass das in der Praxis wirklich nötig ist, kaum jemand wird die Mapping-Attribute dynamisch ändern. Aber ist in jedem Fall konsequent und sehr sauber. Sollte also rein.
Viele Grüße,
Alexander
Was ich auch noch nicht eindeutig entschieden habe: Sollte man den Inhalt der Presentation-messages in Internals, Readings oder Attributen ablegen? Internals wären optisch 'am schönsten', damit die aber einen Neustart überleben müsste man die Logik allerdings weitestgehend selbst implementieren. Bei Readings und Attribute hätte man das quasi automatisch.
Define-parameter wie bei MYSENSORS_SENSOR bzw. MYSENSORS_NODE fallen wg. der möglichen 254 childIds ja eher aus.
Sinnvoll ist das, weil man sonst kaum erkennen kann, wenn die childIds der Sensoren mal versehendlich nicht mehr eindeutig sind.
Gruß,
Norbert
Zitat von: hexenmeister am 21 Oktober 2014, 00:05:35
kaum jemand wird die Mapping-Attribute dynamisch ändern.
Das sehe ich nicht so. Vieleicht nicht oft, aber mindestens dann, wenn man mit dem was Autocreate erzeugt nicht zufrieden ist.
pull-request gemerged und noch mal überarbeitet commit 1 (https://github.com/ntruchsess/fhem-mirror/commit/ad1474eac369f76437a3439f3b49282f9b4776b0), commit 2 (https://github.com/ntruchsess/fhem-mirror/commit/57c49a284c80fb4d11df1c9995ad27b1ae455e9f).
Kann jetzt Typ und Values mappen (die Value-mappings sind optional. Wird beim Mappen kein value-mapping gefunden, wird einfach der unveränderte Wert benutzt):
attr <node> mapReadingType LIGHT switch 0:off 1:on
(dieses Mapping für LIGHT ist schon genau so als default drin, das muss man tatsächlich nicht mehr extra angeben - mir fällt blos grade kein anderes Beispiel mit gemappten values ein)
Das Definitionsbeispiel für den RelayWithButtonActuator.ino verkürzt sich damit drastisch:
define gateway MYSENSORS /dev/ttyUSB0@115200
attr gateway stateFormat connection
define node MYSENSORS_DEVICE <nodeid>
attr node IODev gateway
attr node stateFormat switch_1
attr node setCommands on:LIGHT_1:1 off:LIGHT_1:0
setCommands und set_<type>_<childId> müssen noch dahingehend überarbeitet werden, dass sie die selben Mappings verwenden, damit man 'attr node setCommands on:switch_1:on off:switch_1:off' verwenden kann.
Gruß,
Norbert
setCommands und set_<type>_<childId> kommen jetzt auch mit per mapReadingType_<type> gemappten Readings klar (https://github.com/ntruchsess/fhem-mirror/commit/5ef8f70299415e09505b9c6bebfaa9d195062f7f):
define gateway MYSENSORS /dev/ttyUSB3@115200
attr gateway requestAck 1
attr gateway stateFormat connection
define node MYSENSORS_DEVICE <nodeid>
attr node IODev gateway
attr node stateFormat switch_1
#3 Varianten den switch zu schalten:
#entweder setCommand: (set node on/set node off)
attr node setCommands on:switch_1:on off:switch_1:off
#oder set_<reading> (set node switch_1 on/set node switch_1 off)
attr node set_switch_1 on,off
#oder set_<TYPE> (set LIGHT_1 0/set LIGHT_1 1)
attr node set_LIGHT_1 0,1
der Vollständigkeit halber noch mal die Links auf die Dateien
00_MYSENSORS (https://github.com/ntruchsess/fhem-mirror/raw/mysensors_unified/fhem/FHEM/00_MYSENSORS.pm)
10_MYSENSORS_DEVICE.pm (https://github.com/ntruchsess/fhem-mirror/raw/mysensors_unified/fhem/FHEM/10_MYSENSORS_DEVICE.pm)
lib/Device/MySensors/Constants.pm (https://github.com/ntruchsess/fhem-mirror/raw/mysensors_unified/fhem/FHEM/lib/Device/MySensors/Constants.pm)
lib/Device/MySensors/Message.pm (https://github.com/ntruchsess/fhem-mirror/raw/mysensors_unified/fhem/FHEM/lib/Device/MySensors/Message.pm)
(oder einfach den mysensors_unified-branch (https://github.com/ntruchsess/fhem-mirror/tree/mysensors_unified) aus meinem fhem-mirror auschecken:
git clone https://github.com/ntruchsess/fhem-mirror.git
git checkout mysensors_unified
Wenn Ihr meint, das Modul ist 'reif', dann checke ich es ins SVN ein.
Gruß,
Norbert
Hallo!
So, habe endlich Zeit, habe alles upgedatet, Relay-Node zusammengesteckt, bin am Testen...
Noch ohne autocreate: nach dem Einschalten der Node kommen folgende Meldungen:
2014.10.21 21:48:08.210 3: MYSENSORS: ignoring internal-msg from unknown radioId 127, childId 255 for I_SKETCH_VERSION
2014.10.21 21:48:08.255 3: MYSENSORS: ignoring presentation-msg from unknown radioId 127, childId 1, sensorType 3
Hat Node die ID 127 von dem FHEM bekommen? Oder hatte ich schon etwas im EEPROM? Also EPPROM an dieser Stelle gelöscht. Aber wieder ID 127.
Diese sollte vor der Aufnahme noch nicht vergeben werden. Das klingt nach einem Bug.
Jetzt Test für die Inclusion, ausgelöst durch Taster am Gateway.
Funktioniert, Device wird erstellt.
Ein Paar Warnungen im Log:
2014.10.21 22:09:03.714 1: PERL WARNING: Use of uninitialized value $fields[1] in join or string at FHEM/lib/Device/MySensors/Message.pm line 33.
2014.10.21 22:09:03.715 3: stacktrace:
2014.10.21 22:09:03.715 3: main::__ANON__ called by FHEM/lib/Device/MySensors/Message.pm (33)
2014.10.21 22:09:03.716 3: Device::MySensors::Message::createMsg called by ./FHEM/00_MYSENSORS.pm (369)
2014.10.21 22:09:03.716 3: MYSENSORS::sendMessage called by ./FHEM/10_MYSENSORS_DEVICE.pm (302)
2014.10.21 22:09:03.717 3: MYSENSORS::DEVICE::sendClientMessage called by ./FHEM/10_MYSENSORS_DEVICE.pm (263)
2014.10.21 22:09:03.718 3: MYSENSORS::DEVICE::onInternalMessage called by ./FHEM/00_MYSENSORS.pm (315)
2014.10.21 22:09:03.723 3: MYSENSORS::onInternalMsg called by ./FHEM/00_MYSENSORS.pm (261)
2014.10.21 22:09:03.724 3: MYSENSORS::Read called by fhem.pl (2923)
2014.10.21 22:09:03.724 3: main::CallFn called by fhem.pl (598)
2014.10.21 22:09:03.725 1: PERL WARNING: Use of uninitialized value in sprintf at FHEM/lib/Device/MySensors/Message.pm line 40.
2014.10.21 22:09:03.725 3: stacktrace:
2014.10.21 22:09:03.726 3: main::__ANON__ called by FHEM/lib/Device/MySensors/Message.pm (40)
2014.10.21 22:09:03.726 3: Device::MySensors::Message::dumpMsg called by ./FHEM/00_MYSENSORS.pm (370)
2014.10.21 22:09:03.727 3: MYSENSORS::sendMessage called by ./FHEM/10_MYSENSORS_DEVICE.pm (302)
2014.10.21 22:09:03.727 3: MYSENSORS::DEVICE::sendClientMessage called by ./FHEM/10_MYSENSORS_DEVICE.pm (263)
2014.10.21 22:09:03.728 3: MYSENSORS::DEVICE::onInternalMessage called by ./FHEM/00_MYSENSORS.pm (315)
2014.10.21 22:09:03.729 3: MYSENSORS::onInternalMsg called by ./FHEM/00_MYSENSORS.pm (261)
2014.10.21 22:09:03.729 3: MYSENSORS::Read called by fhem.pl (2923)
2014.10.21 22:09:03.730 3: main::CallFn called by fhem.pl (598)
mit dem gesetzten autocreate funktioniert genauso.
Schalten:
attr MYSENSOR_127 setCommands on:switch_1:on off:switch_1:off
funktioniert, Relay schaltet "falsch rum" (mein Relay-Modul schaltet bei low). Also umdrehen:
attr MYSENSOR_127 setCommands on:switch_1:off off:switch_1:on
Funktioniert richtig. Evtl. wäre sollte bei dieser Änderung, der Schaltbefehl entsprechend dem nuen Zustand gesendet werden? Oder doch besser nicht? Ich neige dazu, das eher nicht zu machen...
attr MYSENSOR_127 set_switch_1 on,off
wieder falsch rum, hier kann man aber wohl nichts 'umdrehen'?
attr MYSENSOR_127 set_LIGHT_1 0,1
erwartungsgemäß 'andersrum'. Auch hier wäre die Option zum 'Umdrehen' hilfreich.
Mein DHT11 Sensor-Node funktioniert auch weiterhin.
Anscheinend sendet der Sketch die Werte nur, wenn sie sich ändern, ansonsten kann ich die unregelmäßige und nicht gleichzitige AKtualisierungen von TEMP und HUM nicht erklären.
requestAck im DEVICE gesetzt: wenn ich die Relay-Node ausmache, on-Befehl sende und wieder die Node einschalte, dann bleibt sie nach der Initialisierung ausgeschaltet.
requestAck im Gateway gesetzt: jetzt bekommt Relay-Node nach dem Einschalten immer den gewünschten Zustand, egal wann geschaltet wurde: vor oder nach dem Auschalten. Mega cool ;)
(übrigens, hier ist es inkonsequent: Bei Device gilt yes/no, beim Gateway wird 1 erwartet.)
Dennoch ein Problem mit dieser Option. Danach wird der Log kontinuierlich zugemüllt:
2014.10.21 22:48:00.831 3: stacktrace:
2014.10.21 22:48:00.832 3: main::__ANON__ called by ./FHEM/10_MYSENSORS_DEVICE.pm (308)
2014.10.21 22:48:00.833 3: MYSENSORS::DEVICE::mapReading called by ./FHEM/10_MYSENSORS_DEVICE.pm (215)
2014.10.21 22:48:00.834 3: MYSENSORS::DEVICE::onSetMessage called by ./FHEM/00_MYSENSORS.pm (295)
2014.10.21 22:48:00.835 3: MYSENSORS::onSetMsg called by ./FHEM/00_MYSENSORS.pm (253)
2014.10.21 22:48:00.836 3: MYSENSORS::Read called by fhem.pl (2923)
2014.10.21 22:48:00.837 3: main::CallFn called by fhem.pl (598)
2014.10.21 22:48:01.842 1: PERL WARNING: Use of uninitialized value $value in hash element at ./FHEM/10_MYSENSORS_DEVICE.pm line 309.
2014.10.21 22:48:01.843 3: stacktrace:
2014.10.21 22:48:01.844 3: main::__ANON__ called by ./FHEM/10_MYSENSORS_DEVICE.pm (308)
2014.10.21 22:48:01.846 3: MYSENSORS::DEVICE::mapReading called by ./FHEM/10_MYSENSORS_DEVICE.pm (215)
2014.10.21 22:48:01.847 3: MYSENSORS::DEVICE::onSetMessage called by ./FHEM/00_MYSENSORS.pm (295)
2014.10.21 22:48:01.847 3: MYSENSORS::onSetMsg called by ./FHEM/00_MYSENSORS.pm (253)
2014.10.21 22:48:01.849 3: MYSENSORS::Read called by fhem.pl (2923)
2014.10.21 22:48:01.849 3: main::CallFn called by fhem.pl (598)
Auschalten von Relay-Node stoppt den Spuk. Löschen von requestAck im Gateway auch.
Liegt hier eine ACK-Schleife vor?
Nach dem wieder setzen setzt von requestAck setzt die Schleife erst wenn Hardware aus und wieder angemacht wird.
Kann ich noch etwas gezielt testen?
Bis dahin werde ich mir erstmal den Code anzuschauen.
Grüße,
Alexander
Bis auf meine Anmerkungen funktioniert bei mir alles sehr stabil und vorhersagbar. Die Schaltbefehle kommen gefühlt verzögerungsfrei.
Sehr gute Arbeit!
Ich denke, ich werde nach und nach andere Gerätschaften von der MySensors-Seite nachbauen und ein oder anderes auch produktiv einsetzen.
Was ich jedoch noch überlege: Ich würde ggf. in meinem haus mehrere (min zwei) Gateways einsetzen müssen. Repeater-Nodes will ich eher vermeiden. Die Frage ist, ob das alles dann noch korrekt funktioniert. Ich vermute, es kann Probleme geben mit der Erkennung von doppelten (durch mehrere Gateways empfangenen) Messages. Eine Message-Nummer oder ID gibt es ja nicht.
Grüße,
Alexander
2. Gateway sollte nicht nötig sein, die Sensoren können ja im Repeater-mode arbeiten. Dazu muss im Setup des Sketches der MySensor::begin-methode der optionale Parameter repeaterMode (Default false) mit true übergeben werden. So ein Repeater-sensor kann dann natürlich nicht sinnvoll mit Batterie laufen. Habe ich aber noch nicht getestet, ich hab erst mal nur 2 nRF24L01 gekauft, da hätte ich besser gleich richtig zulangen sollen.
Die Herrusforderung mit Repeatern ist aber das gleiche, weil deren Messages ja genauso vom Gateway empfangen werden.
Ansonsten könnte man aber auch mehrere Gateways auf unterschiedlichen Kanälen (siehe MyConfig.h) laufen lassen.
Das es RepeaterModus gibt, wusste ich schon, finde aber mehrere Gateways sauberer, denn weniger Latenz und Funk-Last.
Mehrere Kanäle würden ja bedeuten, dass ich mich bei den Sensoren selbst entscheiden soll, mit welchem Gateway sie empfangen werden können. Da würde ich etwas automatisches wünschen, wie bei HomeMatic z.B.
Zitatich hab erst mal nur 2 nRF24L01 gekauft, da hätte ich besser gleich richtig zulangen sollen.
Mir gefällt das System doch besser, als erwartet. Ich werden noch 10 Stück bestellen. :)
Zitat von: hexenmeister am 22 Oktober 2014, 08:42:57
Das es RepeaterModus gibt, wusste ich schon, finde aber mehrere Gateways sauberer, denn weniger Latenz und Funk-Last.
Mehrere Kanäle würden ja bedeuten, dass ich mich bei den Sensoren selbst entscheiden soll, mit welchem Gateway sie empfangen werden können. Da würde ich etwas automatisches wünschen, wie bei HomeMatic z.B.
Mir gefällt das System doch besser, als erwartet. Ich werden noch 10 Stück bestellen. :)
Ach nee :-), hat sich die Anfrage für die Programmierung eines Moduls doch gelohnt. :-)
Wie sieht es denn mit den Störungen im WLAN aus? Hast du etwas davon bemerkt?
Ich zumindest habe keine.
Wann wird es denn eingecheckt?
robin
Aktuell kann man den Sende-/Empfangskanal nur in der MyConfig.h fest einstellen. Natürlich könnte man eine Automatik implementieren, die kostet aber auch wieder Speicher. Kannst Dich ja mal ranmachen, sollte aber optional per #define in der MyConfig.h zu aktivieren sein.
- Ignorieren von ID-Requests wenn inclusion-mode bzw. autocreate nicht aktiv sind ist erledigt.
- requestAck optional am Device auch. Ist 'additiv' - wenn es am Gateway gesetzt ist, gilt es für alle Nodes unabhängig davon, ob es am Node selbst auch aktiviert ist. (Um Missverständnisse auszuschließen kann man das Attribut jetzt nur noch auf 1 setzen oder löschen).
- das 'set_XXX'-attribut habe ich in 'setReading_XXX' umbenannt. Finde ich eindeutiger.
- die on/off - Semantik kannst Du per 'attr xxx mapReadingType_LIGHT switch 0:on 1:off' pro Node umdrehen.
@Robin: Mach dich ans Testen und gib Feedback, ob es architekturell bzw. von der Semantik der Attibute her passt, dann checke ich es ein (Bugs kann man immer noch fixen).
Gruß,
Norbert
@Robin
Ich muss gestehen, Störungen gab es keine (die ich merken konnte). Die Qualität des (Billig)Moduls hat mich schon überrascht. Da die Reichweite (für mich auch eher unerwaret) ganz gut ist, werde ich mein GesamtSystem weiter mit diesen Teile erweitern (versuchen), da sie doch etwas billiger sind als meine FRM12b-Teile und es bereits eine brauchbare Firmware existiert.
Die "Multi-Gateway-Fähigkeit" fehlt mir jedoch noch (Stichwort: Ausfallsicherheit und Reichweite), da reichen mir die Repeater Nodes nicht. Ich möchte auch, dass alle Sensoren mit allen Gateways empfangen werden können.
@Norbert: Was hälst Du von der Idee, dass die Nachrichten ignoriert werden, wenn vor max. X Sekunden (eine ?) eine identische Nachricht verarbeitet wurde? Damit könnte man ja die Duplikate sicher erkennen, Nachteile sehe ich auch keine.
Weiterhin wäre wohl sinnvoll, eine PCB entwickeln und fertigen lassen, wo alles einfach drauf gelötet werden kann (wenn man genug davon bestellt, kostet das etwa 1 Euro pro Stück), diese Fummelei mit den Kabelpeitchen nervt...
Klasse, dass die gestern gefundenen Probleme schon gefixt sind, danke! Ich werde heute Abend wieder testen. Wenn nichts mehr ist und die Doku verständlich ist, kann man IMHO auch einchecken. Wir brauchen aber schon nach Möglichkeit 1-2 weitere Tester mit anderen Konfigurationen, Vorstellungen und Einsatzszenarien.
Grüße,
Alexander
In Bezug auf Reichweitenerhöhung durch Einsatz mehrerer günstig platzierter Gateways sehe ich da keine Probleme. Die Sensoren müssten einfach dem räumlich näher liegenden Gateway per IODev zugeordnet werden. Das Gateway ignoriert Nachrichten, für die es keinen per IODev zugeordneten client findet. Der Autocreate-mechanismus müsste noch das IODev-attribut direkt zuweisen, damit die neu angelegte MYSENSORS_DEVICE-instanz nicht beim anderen Gateway landet.
Der ID_Request ist etwas problematisch, weil jede MYSENSORS-modul instanz davon ausgeht die IDs frei vergeben zu können. Das wäre mit einem Attribut 'last-sensorid' in den Griff zu kriegen, dann könnte man jedem Gateway einfach einen ID-range zur Vergabe zuweisen.
Die Sensoren müsste man natürlich geziehlt anlernen (den inclusion-mode also immer nur bei einem Gateway anschalten).
Lästig ist, dass die Sensoren kein Löschen der gesetzten ID per Knopfdruck (analog zum inclusion-mode-button am Gateway) vorsehen. Hat ein Sensor erst mal eine ID, die nicht im Range des gewünschten Gateways liegt, dann kann der Sensor zwar per IODev diesem Gateway zugeordnet werden, man muss aber beim Anlernen weiterer Sensoren damit rechnen ID-Dubletten zu erzeugen.
Wenn es aber um Redundanz geht ist das eine größere Baustelle. Dafür müsste man den IODev-mechanismus multivalue-tauglich machen, da entwickel ich hier keine Sonderlocke. Ist für mich daher erst mal out-of-scope.
Diskussionen bzw. schon fertige Layouts universell nutzbarer PCBs findest Du im MySensors Hardware Forum.
Ich habe gerade mal die vier Dateien ausgewechselt.
root@raspbmc:/opt/fhem# Undefined subroutine &MYSENSORS::DEVICE::onGatewayStarted called at ./FHEM/00_MYSENSORS.pm line 331.
was fehlt?
robin
falsche Datei? Weil da (https://github.com/ntruchsess/fhem-mirror/blob/mysensors_unified/fhem/FHEM/10_MYSENSORS_DEVICE.pm#L214) isses drin...
jau, alte Dateien.
aber der Temperatursensor verbindet sich nicht
define mytemp MYSENSORS_DEVICE TEMP 21 0
hat sich da in der Definition irgendwas geändert?
gateway sagt folgendes:
connection
startup complete
2014-10-22 19:51:31
arduino serial log sagt folgendes:
sensor started, id 21
send: 21-21-0-0 s=255,c=0,t=17,pt=0,l=3,st=ok:1.4
send: 21-21-0-0 s=255,c=3,t=6,pt=1,l=1,st=ok:0
send: 21-21-0-0 s=255,c=3,t=11,pt=0,l=18,st=ok:Temperature Sensor
send: 21-21-0-0 s=255,c=3,t=12,pt=0,l=3,st=ok:1.0
send: 21-21-0-0 s=0,c=0,t=6,pt=0,l=3,st=ok:1.4
send: 21-21-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:23.1
Update:
Aber natürlich hat sich was geändert.
sieht jetzt bei mir so aus:
define jeelinktemp MYSENSORS /dev/ttyUSB0@115200
attr jeelinktemp room mysensors
attr jeelinktemp stateFormat connection
define temperatursensor MYSENSORS_DEVICE 21
attr temperatursensor IODev jeelinktemp
attr temperatursensor room mysensors
bei 3 18B20 Temperatursensoren kommt sogar ein Ergebnis raus.
temperature_0
25.4
2014-10-22 20:21:24
temperature_1
26.1
2014-10-22 20:21:24
temperature_2
25.9
2014-10-22 20:21:24
Nur wie kommt man an die Channel ID, wenn man nicht gerade den Sensor an den Serial-Monitor anschließen möchte?
Antwort:
Inclusion Mode beim Gateway einschalten. Damit "horcht" das Gateway für eine kurze Zeit in seinem Netzwerk herum, ob es einen neuen Sensor gibt. Dann den neuen hinzuzufügenden Sensor einmal resetten und schon nimmt das Gateway (bzw. Fhem) den Sensor in seiner Liste auf.
Anschließend wird dann sowas erzeugt:
CFGFN
DEF
20
IODev
jeelinktemp
I_SKETCH_NAME
Soil Moisture Sensor
I_SKETCH_VERSION
1.0
NAME
MYSENSOR_20
NR
1321
STATE
???
TYPE
MYSENSORS_DEVICE
ack
0
radioId
20
Readings
V_TRIPPED_0
0
2014-10-22 20:35:11
Sogar mit der Sketch-Version und Sensor-Typ vom Sensor-Sketch, prima!
Zitat von: fh168
das gateway verliert die connection.. wenn ich wieder auf connect draufklicke dann gehts wieder für eine gewisse zeit.
liegt vermutlich am Gateway selber. Wenn Du 'set <gateway> connect' aufrufst, wird die Serielle Schnittstelle geschlossen und wieder geöffnet. Das setzt den Arduino per Hardwarereset (DTR der Schnittstelle ist mit Reset verbunden) zurück. Gibt's was verwertbares aus dem Log? Ggf. mit verbose = 5 am Gateway noch mal laufen lassen. Ist 'requestAck' am Gateway-device aktiviert?
Gruß,
Norbert
Zitat von: ntruchsess am 22 Oktober 2014, 22:09:32
liegt vermutlich am Gateway selber.
Vermute ich auch. Mein GateWay läuft seit Tagen ohne Reset und Probleme. Und das obwohl es einfach wild auf dem Breadboard zusammengesteckt ist.
Zitat von: hexenmeister am 22 Oktober 2014, 22:13:03Mein GateWay läuft seit Tagen ohne Reset und Probleme.
Das nehme ich jetzt mal zum Anlass die Module in's SVN einzuchecken (http://sourceforge.net/p/fhem/code/6800/). Ab jetzt werden die Bugs auch immer gleich dort gefixed. Patches am liebsten bitte per pull-request gegen master in meinem fhem-mirror auf github. (https://github.com/ntruchsess/fhem-mirror)
Gruß,
Norbert
Habe ein Bischen die neue Version getestet....
Ohne Inclusion keine ID-Vergabe -> fix bestätigt
Wieso wird eigentlich ID 127 vergeben?
Default soll doch 20 sein (laut Doku). Ich hab kein Attribut definiert.
On/Off 'undrehen' -> funktioniert
(attr MYSENSOR_127 mapReadingType_LIGHT switch 0:on 1:off)
requeatAck funktioniert jetzt ohne Warnings-Schleife.
Warnins (z.B. beim beim Reset von RelayNode) kommen immer noch:
2014.10.22 22:17:55.053 1: PERL WARNING: Use of uninitialized value $fields[1] in join or string at FHEM/lib/Device/MySensors/Message.pm line 33.
2014.10.22 22:17:55.053 3: stacktrace:
2014.10.22 22:17:55.054 3: main::__ANON__ called by FHEM/lib/Device/MySensors/Message.pm (33)
2014.10.22 22:17:55.055 3: Device::MySensors::Message::createMsg called by ./FHEM/00_MYSENSORS.pm (373)
2014.10.22 22:17:55.055 3: MYSENSORS::sendMessage called by ./FHEM/10_MYSENSORS_DEVICE.pm (316)
2014.10.22 22:17:55.055 3: MYSENSORS::DEVICE::sendClientMessage called by ./FHEM/10_MYSENSORS_DEVICE.pm (276)
2014.10.22 22:17:55.056 3: MYSENSORS::DEVICE::onInternalMessage called by ./FHEM/00_MYSENSORS.pm (315)
2014.10.22 22:17:55.056 3: MYSENSORS::onInternalMsg called by ./FHEM/00_MYSENSORS.pm (261)
2014.10.22 22:17:55.057 3: MYSENSORS::Read called by fhem.pl (2923)
2014.10.22 22:17:55.057 3: main::CallFn called by fhem.pl (598)
2014.10.22 22:17:55.061 1: PERL WARNING: Use of uninitialized value in sprintf at FHEM/lib/Device/MySensors/Message.pm line 40.
2014.10.22 22:17:55.061 3: stacktrace:
2014.10.22 22:17:55.063 3: main::__ANON__ called by FHEM/lib/Device/MySensors/Message.pm (40)
2014.10.22 22:17:55.063 3: Device::MySensors::Message::dumpMsg called by ./FHEM/00_MYSENSORS.pm (374)
2014.10.22 22:17:55.064 3: MYSENSORS::sendMessage called by ./FHEM/10_MYSENSORS_DEVICE.pm (316)
2014.10.22 22:17:55.064 3: MYSENSORS::DEVICE::sendClientMessage called by ./FHEM/10_MYSENSORS_DEVICE.pm (276)
2014.10.22 22:17:55.065 3: MYSENSORS::DEVICE::onInternalMessage called by ./FHEM/00_MYSENSORS.pm (315)
2014.10.22 22:17:55.066 3: MYSENSORS::onInternalMsg called by ./FHEM/00_MYSENSORS.pm (261)
2014.10.22 22:17:55.066 3: MYSENSORS::Read called by fhem.pl (2923)
2014.10.22 22:17:55.067 3: main::CallFn called by fhem.pl (598)
2014.10.22 22:18:00.028 3: a_automation_heartbeat: ctrl_last_RL_WZ_LightZitatattr <name> mapReadingType_<reading> <new reading name> [<value>:<mappedvalue>]*
configures reading user names that should be used instead of technical names
Ich fürchte, hier wird leider kein Benutzer verstehen, was die technischen Namen sind und wie sie genau heißen. Evtl. wäre besser zu ermöglichen, die sichtbaren (also eingentlich bereits gemappten) Namen anzupassen.
Irgendwie ist das noch schwer durchzublicken...
verwirrend, dass
attr MYSENSOR_127 setReading_switch_1 on,off
geht, aber nicht
attr MYSENSOR_127 setReading_switch on,off
Insgesamt läuft Modul gut. :)
EDIT: Bildchen ;)
sub mapReading($$) {
my($hash, $type, $childId, $value) = @_;
Da fehlen noch zwei $$. Mein Perl mag es nicht so ;)
Danke noch mal für die Warnings, diesmal passen die Zeilennummern auch zum code ;-)
Zitat von: hexenmeister am 22 Oktober 2014, 23:13:13
Wieso wird eigentlich ID 127 vergeben?
Default soll doch 20 sein (laut Doku). Ich hab kein Attribut definiert.
Das ist so, weil 'keys' in perl kein sortiertes Array zurückgibt ;-) (ok, könnte man einfach ändern)
20 ist nur der Vorgabewert für die kleinste mögliche ID. Das Gateway zählt nicht einfach hoch, sondern prüft, welche IDs die registrierten Nodes schon haben.
Zitat von: hexenmeister am 22 Oktober 2014, 23:13:13
configures reading user names that should be used instead of technical names
Ich fürchte, hier wird leider kein Benutzer verstehen, was die technischen Namen sind und wie sie genau heißen.
ich gebe zu, das verstehe ich losgelöst vom Kontext auch nicht ;-) Irgendwie ist der Satz bei copy&paste zerwürfelt worden. 'technical names' ist eh überholt. Schreib was, was auch ein DAU versteht - ich bin da etwas 'betriebsblind'
Zitat von: hexenmeister am 22 Oktober 2014, 23:13:13
verwirrend, dass
attr MYSENSOR_127 setReading_switch_1 on,off
geht, aber nicht
attr MYSENSOR_127 setReading_switch on,off
das Reading heißt ja 'switch_1' und nicht 'switch'. Das könnte man nur besser machen, wenn man Mappings für alle bekannten Sketches hinterlegt (aber man kann sich nicht darauf verlassen, dass nicht jemand den Sketch verändert ohne den Namen zu ändern). Oder hast Du einen schlauen Vorschlag, wie man die childIds aus den Readings weglassen kann ohne Konflikte zu bekommen, wenn doch plötzlich ein Wert zu einem schon von einer anderen childId benutzen Variablentyp kommt (Und das ganze reproduzierbar und unabhängig von der Reihenfolge in der die Werte eintreffen).
Zitat von: hexenmeister am 22 Oktober 2014, 23:13:13
Insgesamt läuft Modul gut. :)
danke für die Blumen :-)
- Norbert
hab die Warnings mal nach bestem Wissen und Gewissen behoben... (http://sourceforge.net/p/fhem/code/6801/)
... und gleich mal mit einem EthernetGateway getestet.
define gateway 192.168.0.6:5003
tut (fast) wie es soll. Schickt nur keine 'I_STARTUP_COMPLETE'-message - das hat aber (abgesehen vom sichtbaren STATE) aktuell keine weiteren Auswirkungen.
Gruß,
Norbert
Ethernet gateway läuft ....
Bastelstunde 8)
Es ist schon fast langweilig. Man steckt es zusammen, schaltet ein und... es funktioniert. Da ich keinen freien Transmitter mehr habe, habe ich beschlossen, meinen Humidity-Sensor zu erweitern. Kurzerhand zwei Sketches gemerged und... DEVICE hat ein neues Reading. Da zahlt sich die universale Aufbau aus.
Anregungen/Wünsche/Kommentare ;)
Warnings sind gefühlt weniger geworden. Bei Reset des Nodes kommen aber noch:
2014.10.23 23:04:51.245 1: PERL WARNING: Use of uninitialized value $fields[1] in join or string at FHEM/lib/Device/MySensors/Message.pm line 33.
2014.10.23 23:04:51.246 3: stacktrace:
2014.10.23 23:04:51.246 3: main::__ANON__ called by FHEM/lib/Device/MySensors/Message.pm (33)
2014.10.23 23:04:51.247 3: Device::MySensors::Message::createMsg called by ./FHEM/00_MYSENSORS.pm (373)
2014.10.23 23:04:51.247 3: MYSENSORS::sendMessage called by ./FHEM/10_MYSENSORS_DEVICE.pm (316)
2014.10.23 23:04:51.248 3: MYSENSORS::DEVICE::sendClientMessage called by ./FHEM/10_MYSENSORS_DEVICE.pm (276)
2014.10.23 23:04:51.249 3: MYSENSORS::DEVICE::onInternalMessage called by ./FHEM/00_MYSENSORS.pm (315)
2014.10.23 23:04:51.249 3: MYSENSORS::onInternalMsg called by ./FHEM/00_MYSENSORS.pm (261)
2014.10.23 23:04:51.250 3: MYSENSORS::Read called by fhem.pl (2923)
2014.10.23 23:04:51.250 3: main::CallFn called by fhem.pl (598)
2014.10.23 23:04:51.251 1: PERL WARNING: Use of uninitialized value in sprintf at FHEM/lib/Device/MySensors/Message.pm line 40.
2014.10.23 23:04:51.251 3: stacktrace:
2014.10.23 23:04:51.252 3: main::__ANON__ called by FHEM/lib/Device/MySensors/Message.pm (40)
2014.10.23 23:04:51.252 3: Device::MySensors::Message::dumpMsg called by ./FHEM/00_MYSENSORS.pm (374)
2014.10.23 23:04:51.253 3: MYSENSORS::sendMessage called by ./FHEM/10_MYSENSORS_DEVICE.pm (316)
2014.10.23 23:04:51.253 3: MYSENSORS::DEVICE::sendClientMessage called by ./FHEM/10_MYSENSORS_DEVICE.pm (276)
2014.10.23 23:04:51.254 3: MYSENSORS::DEVICE::onInternalMessage called by ./FHEM/00_MYSENSORS.pm (315)
2014.10.23 23:04:51.255 3: MYSENSORS::onInternalMsg called by ./FHEM/00_MYSENSORS.pm (261)
2014.10.23 23:04:51.255 3: MYSENSORS::Read called by fhem.pl (2923)
2014.10.23 23:04:51.256 3: main::CallFn called by fhem.pl (598)Es wäre schön, wenn nach dem Remappen die alten Readings gelöscht werden:
attr node mapReadingType_DISTANCE distancedie alte V_DISTANCE_2 soll weg.
Man könnte distance auch analog temperatur und humidity fest integrieren.
Es wäre hilfreich, wenn man die ID-Vergabe etwas beeinflüssen könnte.
Mir schwebt folgendes vor:
- Min/Max ID per Attribut definieren (damit man mehrere unanhängige Ranges für mehrere IOs definieren kann.)
- einmalig die nächste zu vergebende ID bestimmen: Damit wäre möglich, einem Sensor eine bestimmte ID zu verpassen (die er beim Drücken des Inclusion Knopfes dann auch sicher bekommt). Ich denke hier an ein set-Befehl und eine Anzeige in Internals (oder Readings bzw. Attribute?)
ZitatSchreib was, was auch ein DAU versteht
Ich denke, hier ist das Problem nicht die Formulierung, sondern die Funktionalität selbst.
Mein Vorschlag wie schon vorher: die Attribute soll die sichtbaren Readings umbenennen, unanhängig davon, ob das schon intern 'umbenannt' wurde oder nicht. Vielleicht sogar so: wenn die Angabe mit Zahl gemacht wird (temperature1) dann soll nur ein bestimmtes Readings umbnannt werden, wenn ohne (temperature) dann die ganze Gruppe, also alle temperature.*
Dann könnte ich ein verständliches Text dazu schreiben ;)
also anstatt diesem:
attr node mapReadingType_TEMP xyzdieses:
attr node mapReadingType_temperature xyzZur Frage nach der Benennung der Readings:
Von Hintelegen aller bekannten Sketches im Modul halte ich nichts.
Aus meiner Sicht wäre ganz gut, wenn bei der ersten Reading die Nummer entfallen könnte (weil die allermeisten Sensoren keine mehrere gleichartigen Readings haben), die andere gleichartigen werden dann durchnumeriert. Jede Art beginnt mit 1:
temperature
temperature1
temperature2
humidity
humidity1Zum eindeutigen und wiederholbaren Erkennen sollten doch die Presentation Meldungen reichen. Jeder Sensor sendet diese beim Start, noch bevor die erste Werte kommen. Man könnte sie alle sammeln, sortieren, zur Namensmapping nutzen. Das dürfte eine sicherre Methode sein.
(Ich könnte zum Testen einen Sensor mit mehreren gleichartigen Dingen basteln.)
Was hälst du davon?
Grüße,
Alexander
Hallo Norbert, Hallo Alexander,
Vielen Dank an Euch beiden fuer diese grandiose Arbeit!
Das Modul funktioniert einwandfrei, ich bin total begeistert.
Vorab noch eine Entschuldigung - ist mein erster Beitrag im forum, Bitte um Nachsicht, wenn das Format schrecklich ist/wird.
Ich habe bisher mit einem Node mit mehreren Aktoren (Relais) getestet - funktioniert prima
zur Konfiguration/Implementierung hab noch ein paar Fragen
1) inclusion mode, wird der Node angelegt, das Relay aber nicht
... es koennte folgendes in set angelegt/zugefuegt werden
"LIGHT_x" => [qw(on off)],
"DIMMER_x" => "",
+ aktueller Wert des Pins in die Readings ????
... bin mir nicht sicher, ob man den abfragen kann
Frage: Kann man das implementieren?
2) wie sieht das setCommands bei einen V_DIMMER, V_LIGHT_LEVEL, aus?
Wunsch:
fhem:> attr MYSENSOR_1 setCommands dimmer1:DIMMER_1:0
fhem:> set MYSENSOR_1 dimmer1 50
Aenderung: 10_NYSENSORS_DEVICE.pm:132
my ($type,$childId,$mappedValue);
if (defined @values) {
my $value = @values ? join " ",@values : "";
($type,$childId,$mappedValue) = readingToType($hash,$1,$value);
}
else{
($type,$childId,$mappedValue) = readingToType($hash,$setcommand->{var},$setcommand->{val});
}
Workaround:
fhem:> attr MYSENSOR_1 setCommands DIMMER_1:DIMMER_1:1
fhem:> attr MYSENSOR_1 setCommands DIMMER_2:DIMMER_2:1
fhem:> set MYSENSOR_1 DIMMER_1 50
fhem:> set MYSENSOR_1 DIMMER_1 80
Frage: Kann man das implementieren, oder besser den Workaround verwenden?
3) bei den Readings erscheinen unterschiedliche ja nach Inhalt von requestAck:
wenn requestAck == 1 wird switch_x aktualisier
wenn requestAck == 0 wird LIGHT_x aktualisier
evtl. hier %static_mappings
---
LIGHT_1 0 2014-10-24 04:56:50
LIGHT_2 0 2014-10-24 04:59:27
switch_1 on 2014-10-24 04:46:14
switch_2 on 2014-10-24 04:19:35
Frage: Kann ich das konfigurieren, dass die Readings immer im gleichen Wert
ankommen, und wenn ja wie?
4) set MYSENSOR_1 LIGHT_1 1
=> FM: Unknown argument LIGHT_1, choose one of clear off1 off2 on1 on2 reboot time
- sollte aber gehen: siehe 10_MYSENSORS_DEVICE.pm:124
$command =~ /^(.+_\d+)$/ and do {
- evtl. moeglich, wenn LIGHT_x automatisch angelegt wird (siehe Pkt.1)
Workaround:
fhem:> attr MYSENSOR_1 setCommands LIGHT_1:LIGHT_1:1 LIGHT_2:LIGHT_2:1
fhem:> attr MYSENSOR_1 setCommands LIGHT_2:LIGHT_2:1
fhem:> set MYSENSOR_1 LIGHT_1 1
fhem:> set MYSENSOR_1 LIGHT_1 0
fhem:> set MYSENSOR_1 LIGHT_2 1
fhem:> set MYSENSOR_1 LIGHT_2 0
Frage: Kann man das implementieren, oder besser den Workaround verwenden?
Vielen Vielen Dank nochmals an Euch!! und Viele Gruesse
enrico
zu 1) ich verstehe leider nicht, was Du genau meinst. Ich glaube Du beziehst Dich hier auf eine veraltete Version. Released sind die Dateien 00_MYSENSORS.pm und 10_MYSENSORS_DEVICE.pm. In letzterer sieht das vordefinierte Mapping so aus:
my %static_mappings = (
V_TEMP => { type => "temperature" },
V_HUM => { type => "humidity" },
V_PRESSURE => { type => "pressure" },
V_LIGHT_LEVEL => { type => "brightness" },
V_LIGHT => { type => "switch", val => { 0 => 'off', 1 => 'on' }},
);
Da fehlen natürlich noch jede Menge Variablentypen. Was soll den für V_DIMM erscheinen? Einfach nur 'dimm'?
Der Aktuelle Code ist im SVN. Sollte per update rüberkommen. Wenn Du einen eigenen Sketch (mit mehreren Aktoren) verwendest, poste den bitte unbedingt auch. (Das automatische Anlegen basiert auf den Presentation-messages des Nodes, wenn der z.B. nicht alle Sensoren/Aktoren meldet, dann geht's nicht)
2) Das Attribut 'setCommands' kann immer nur einmal pro instanz definiert werden. Das sind Kommandos, die man ohne Angabe eines Wertes abschicken will. Also so was wie 'set Wohnzimmerlicht on'. Man muss alle Kommandos gemeinsam in einem Attribut definieren.
Das was Du vermultlich machen willst sollte etwa so gehen:
'setReadings_DIMMER_1 0,10,20,30,40,50,60,70,80,90,100'
'setReadings_DIMMER_2 0,10,20,30,40,50,60,70,80,90,100'
3)
das mit dem requestAck klingt nach Bug. Schau ich mir an, würde aber gerne vorher wissen, welche Version Du genau verwendest. Deinen Sketch muss ich dazu auch sehen, weil das Update der Readings bei aktiviertem RequestAck durch den Inhalt der Achnowledge-message des Sensors bestimmt wird.
4) LIGHT_1 heißt in der Released version ohne eigenes mapReadingType-attribut 'switch_1' und kann mit per 'set xxx switch_1 on' bzw. 'set_xxx switch_2 off' ohne weitere Einstellungen geschaltet werden.
Gruß,
Norbert
Hallo!
Interessante Sache, das MySensors Thema!
Dazu noch eine Frage: Bei Homematic gibt es ja nach dem Schalten eine Rückmeldung von den Sensoren, ob die Lampe nun erfolgreich eingeschaltet wurde. Ist das bei MySensors genauso?
Wenn ja - dann hab ich genau sowas gesucht! MySensors hat ja wahnsinnig viele Möglichkeiten an Sensoren/Aktoren!!
Zitat von: thunder1902 am 24 Oktober 2014, 08:10:21
...Rückmeldung von den Sensoren, ob die Lampe nun erfolgreich eingeschaltet wurde. Ist das bei MySensors genauso?
ja, kann mit dem Attribut 'requestAck' an- bzw. abgestellt werden.
Hallo Alex,
danke für die umfangreiche Rückmeldung.
Zitat von: hexenmeister am 23 Oktober 2014, 23:17:52
Warnings sind gefühlt weniger geworden. Bei Reset des Nodes kommen aber noch: (perl-warnings entsorgt...)
Diese Warnings sollten jetzt weg sein (http://sourceforge.net/p/fhem/code/6803/).
Zitat von: hexenmeister am 23 Oktober 2014, 23:17:52
Mir schwebt folgendes vor:
- Min/Max ID per Attribut definieren (damit man mehrere unanhängige Ranges für mehrere IOs definieren kann.)
+ es gibt ein neues Attribute 'last-sensorid' mit dem man den Range der zu vergebenden Ids nach oben hin begrenzen kann. ('first-sensorid' gab es ja schon).
Die id's werden jetzt der Reihe nach aus dem Konfigurierten Range (Default 20-254) vergeben. Schon belegte IDs werden dabei übersprungen.
Zitat von: hexenmeister am 23 Oktober 2014, 23:17:52
Aus meiner Sicht wäre ganz gut, wenn bei der ersten Reading die Nummer entfallen könnte
[...]
Zum eindeutigen und wiederholbaren Erkennen sollten doch die Presentation Meldungen reichen.
Dafür müsste man die Zuordnung Reading-name <-> childId in Attribute(n) speichen, weil man die Presentation-messages nicht nochmal anfordern kann und die childIds nicht einfach <gewünschteReadingNummer>-1 sind. Sonst wäre die Zuordnung beim FHEM-neustart weg.
also etwa so:
attr mapReading_<name> <childId> <readingType>
attr mapReading_temperature5 25 temperature
Damit wäre allerdings die durch 'mapReadingType_<basename> <type>' von Dir gewünschte einfache Zuordnung für alle Readings eines Typs hinfällig.
Gruß,
Norbert
Hallo Norbert,
Vielen Dank fuer die schnelle Antwort!
Zu den verwendeten Versionen:
fhem: fhem-code-6803-trunk (hab ich grad aktualisiert)
MySensors: Standard-Beispiel fuer Relays (mit 2 Relais)
https://github.com/mysensors/Arduino/blob/master/libraries/MySensors/examples/RelayActuator/RelayActuator.ino
zu 1)
bei aktiven inclusion-mode ist im logfile folgendes zu sehen
2014.10.24 08:53:06 5: MYSENSORS Read: Rx: fr=001 ci=255 c=000(C_PRESENTATION) st=018(S_ARDUINO_REPEATER_NODE) ack=0 '1.4
2014.10.24 08:53:06 5: MYSENSORS Read: Rx: fr=001 ci=003 c=000(C_PRESENTATION) st=000(S_DOOR ) ack=1 '
2014.10.24 08:53:08 5: MYSENSORS Read: Rx: fr=001 ci=001 c=000(C_PRESENTATION) st=003(S_LIGHT ) ack=0 '1.4
2014.10.24 08:53:08 5: MYSENSORS Read: Rx: fr=001 ci=002 c=000(C_PRESENTATION) st=003(S_LIGHT ) ack=0 '1.4
... im fhem wird folgendes angelegt:
CFGFN
DEF 1
IODev gateway
I_SKETCH_NAME Relay
I_SKETCH_VERSION 1.0
NAME MYSENSOR_1
NR 31
STATE ???
TYPE MYSENSORS_DEVICE
ack 0
radioId 1
... da kann man die Sensoren/Aktoren nicht sehen, die bekommt man nur raus, wenn man ins logfile schaut.
Mein Wunsch waere, dass die automatisch unter den Sets auftauchen.
... es koennte doch fuer die Aktoren das Kommando aus Punkt 2 automatisch aufgerufen werden.
z.B.: attr MYSENSOR_1 setReading_switch_1 0,1
Weiter waere es klasse, wenn man beim inclusion-mode oder per get-Funktion den aktuellen Wert der Aktoren/Sensoren abfragen kann.
Da man sonst keinen aktuellen Zustand/Wert der Aktoren bekommt, bis man den Wert einmal geaendert hat.
bin mir nicht sicher, ob das mit den mysensor-protokoll geht
evtl. so
NODE_ID, CHILD_ID, TYPE , ACK, SUB-TYPE, PAYLOAD
1 , 1 , C_REQ, [01], S_LIGHT
1 , 2 , C_REQ, [01], S_LIGHT
1 , 3 , C_REQ, [01], S_DOOR
wollte das so ausprobieren ...
fhem:> {MYSENSORS::DEVICE::sendClientMessage($defs{MYSENSOR_1}, childId => 1, cmd => 2, subType => 2)}
kommt aber nichts vom node zurueck.
2014.10.24 10:42:33 5: Cmd: >{MYSENSORS::DEVICE::sendClientMessage($defs{MYSENSOR_1}, childId => 1, cmd => 2, subType => 2)}<
2014.10.24 10:42:33 5: MYSENSORS send: Rx: fr=001 ci=001 c=002(C_REQ ) st=002(V_LIGHT ) ack=0 '
2014.10.24 10:42:33 5: MYSENSORS/RAW: /0;
2014.10.24 10:42:33 5: MYSENSORS/RAW: 0;/0;3;0;9;send
2014.10.24 10:42:33 5: MYSENSORS/RAW: 0;0;3;0;9;send/: 0-0-1-1 s
2014.10.24 10:42:33 5: MYSENSORS/RAW: 0;0;3;0;9;send: 0-0-1-1 s/=1,c=2,t=2,p
2014.10.24 10:42:33 5: MYSENSORS/RAW: 0;0;3;0;9;send: 0-0-1-1 s=1,c=2,t=2,p/t=0,l=0,st=o
2014.10.24 10:42:33 5: MYSENSORS/RAW: 0;0;3;0;9;send: 0-0-1-1 s=1,c=2,t=2,pt=0,l=0,st=o/k:
2014.10.24 10:42:33 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'send: 0-0-1-1 s=1,c=2,t=2,pt=0,l=0,st=ok:
2014.10.24 10:42:33 5: MYSENSORS gateway gateway: send: 0-0-1-1 s=1,c=2,t=2,pt=0,l=0,st=ok:
zu 2)
ok, verstanden. funktioniert. Merci!
fhem:> attr MYSENSOR_1 setReading_switch_1 0,1
dann geht folgendes ...
fhem:> set MYSENSOR_1 switch_1 0
.... genau das hab ich gesucht!
zu 3)
ist auch mit der aktuellen Version (fhem-code-6803-trunk) reproduzierbar.
wenn man in den sets den falschen Wert hat.
fhem:> attr MYSENSOR_1 setReading_LIGHT_1 0,1
mit den richtigen Werten (siehe Pkt.2) tritt das Problem nicht auf.
fhem:> attr MYSENSOR_1 setReading_switch_1 0,1
zu 4)
hab ich probiert ...
fhem:> set MYSENSOR_1 switch_1 on
funktioniert, wenn man die Aktoren wie unter Punkt 2, von Dir beschrieben anlegt.
Die Punkte 2,3,4 haben funktioniert, mit dem Tipp in Punkt 2.
Vielen Dank fuer die schnelle Hilfe!!
Punkt 1 - waere klasse wenn das automatisch geht.
zu 1) verstanden. Autocreate der passenden Attribute basierend auf den Presentation-messages war eh noch auf meiner ToDo-liste. Das ist aber immer erst der zweite Schritt - erst muss man sich über die Semantik der zu erzeugenden Attribute einig sein, sonst hat man bei jeder Änderung die doppelte Arbeit.
Hallo Norbert,
Vielen Dank fuer die schnelle Antwort!
Dann war ich mit dem autocreate wohl etwas zu ungeduldig :-) sorry!
Mit den Tipp von Dir funktioniert ja erst mal alles, dann kan ich noch ein wenig basteln und testen.
Vielen Dank und Viele Gruesse
enrico
Ich habe immer noch das Problem das beim Ethernet-Gateway und auch beim Serial Gateway (2 unterschiedliche Arduinos und Transceiver) nach einiger Zeit keine Daten mehr kommen. ACK habe ich auf 1 gesetzt. Gateway sagt auch connect an. Ich habe 3 unterschiedliche Sensoren hier (Hum, Vtemp und V_Tripped). Es kommt nach einiger Zeit nichts mehr an.
Fehlermeldung im Log (verbose 5), keine ahnung ob das was bringt...
2014.10.24 20:01:54 1: PERL WARNING: Argument "" isn't numeric in sprintf at FHEM/lib/Device/MySensors/Message.pm line 40.
2014.10.24 20:01:54 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at FHEM/lib/Device/MySensors/Message.pm line 40.
2014.10.24 20:01:56 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at FHEM/lib/Device/MySensors/Message.pm line 40.
2014.10.24 20:01:57 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at FHEM/lib/Device/MySensors/Message.pm line 40.
robin
Wie lange dauert es, bis die Daten nicht mehr kommen?
Wie gesagt, bei mir läuft GateWay seit Tagen ohne Unterbrechung.
Die Sensoren lasse ich nicht durchlaufen, aber zum Testen liefen sie schon vielen Stunden am Stück.
Mittlerweile habe ich hier einen etwas monströsen Aufbau mit DHT11 (Temperatur+Feuchte), BH1750 (Licht) und HC-SR04 (Entfernung).
Sketches lassen sich sehr einfach erweitern. Und es sind immer noch erst 69% Flash und 45% RAM des Mini Pro belegt.
Die Lib für BH1750 ist aber doof (nicht genau genug im unteren Bereich, nach oben arg begrenzt). Ich habe mal eine bessere erstellt: http://s6z.de/cms/index.php/arduino/sensoren/15-umgebungslichtsensor-bh1750
Kann aber ohne Anpassung so nicht verwendet werden (allein weil 2 Bytes für den Wert nicht reichen)
30 minuten ungefähr
auch interessant: er zeigt connected an, obwohl das Netzwerk-kabel schon längst wieder abgezogen ist.
(auch im state)
connection
connected
2014-10-24 21:15:01
erst nach shutdown restart steht im state disconnected
zu Net-Gateway kann ich leider nichts sagen, muss ich mal erst einen aufbauen (habe gerade keine Transmitter mehr).
Aber mit dem Serial Gateway laufen die Sensoren definitiv wesentlich länger als eine halbe Stunde problemlos.
Um das Problem einzugrenzen: hast Du an Deinen Gateway die LEDs angeschlossen, dann kannst Du sehen, ob gerade gesendet/empfangen wird. Wäre interessant festzustellen, ob die Daten empfangen werden und nicht zu FHEM weitergeleitet werden, oder gar nicht erst vom Sensor losgesendet werden. Die Beispielsketches senden übrigens nur, wenn sich der Wert ändert. Zum Testen wäre sinnvoll, diese Einschränkung auszubauen.
Hallo Norbert,
ich teste ein wenig weiter. Die Warnings sind wesentlich weniger geworden. Beim Reset habe ich keine mehr. Trotzdem finde ich im Log mal welche, habe aber bis jetzt nicht sicher provozieren können:
2014.10.24 23:02:09.817 1: PERL WARNING: Argument "" isn't numeric in sprintf at FHEM/lib/Device/MySensors/Message.pm line 42.
2014.10.24 23:02:09.818 3: stacktrace:
2014.10.24 23:02:09.819 3: main::__ANON__ called by FHEM/lib/Device/MySensors/Message.pm (42)
2014.10.24 23:02:09.820 3: Device::MySensors::Message::dumpMsg called by ./FHEM/00_MYSENSORS.pm (374)
2014.10.24 23:02:09.821 3: MYSENSORS::sendMessage called by ./FHEM/10_MYSENSORS_DEVICE.pm (316)
2014.10.24 23:02:09.821 3: MYSENSORS::DEVICE::sendClientMessage called by ./FHEM/10_MYSENSORS_DEVICE.pm (276)
2014.10.24 23:02:09.822 3: MYSENSORS::DEVICE::onInternalMessage called by ./FHEM/00_MYSENSORS.pm (315)
2014.10.24 23:02:09.823 3: MYSENSORS::onInternalMsg called by ./FHEM/00_MYSENSORS.pm (261)
2014.10.24 23:02:09.823 3: MYSENSORS::Read called by fhem.pl (2923)
2014.10.24 23:02:09.824 3: main::CallFn called by fhem.pl (598)
ok, ich werde mir mal die LEDs mit einbauen.
Das nur ein Wert gesendet wird, wenn sich was ändert, finde ich schon mal gut. Ist mir auch schon aufgefallen.
Ich habe das Problem mit USB-Serial auch gehabt mit einem anderen Arduino-Aufbau, darum wundert es mich jetzt, das ich den gleichen Fehler im Ethernet-Aufbau auch habe.
Ich werde mein 'Monster-Sensor' an eine Batterie anschliessen und die Nacht durchlaufen lassen. Mal sehen, ob ich das Problem nachstellen kann.
Glaube ich aber nicht, 30 Minuten und dann nichts würde mir längst auffallen.
Hast Du schon mal im Log nachgesehen mit LogLevel 5, kommt da was von MySensors wenn die Werte nicht mehr aktualisiert werden?
Ich werde für meine Sketches dieses Verhalten sicher ändern. Dass nur eine Änderung gesendet wird ist schon nicht schlecht, aber zu grob.
Bei Licht will ich z.B. erst senden, wenn die Änderung mehr als 10% betrug (weil ansonsten zu 'unruhig' wird und der Messbereich logarithmisch ist).
Gleichzeitig will ich aber spätestens nach 60 Minuten einen Wert (für jede Reading) haben, damit ich die 'tote' Sensoren sicher als solche erkennen kann.
@Norbert
Das die Zuordnung mit dem Neustart weg ist, ist in der Tat ein Problem.
Ich probieren mal das Problem von der anderen Seite zu beleuchten.
Was ich erreichen will ist... Die meisten Sensoren dürften in der Praxis die T/H Sensoren mit nur je einem Wert pro Art sein. Es wäre schön (und mit den HM und anderen Sensoren homogen) wenn die Readings 'temperature' und 'humidity' heißen würden. Soweit klar. Die Frage ist, wie man das praxistauglich erreicht.
Wäre vlt. ein gangbarer Weg, wenn man den Inklusion-Vorgang, genauer gesagt dabei empfangenen Presentation-Messages für den Aufbau von Attributen benutzt, die genau solches Mapping definieren? Dafür braucht man (zusätzlich zum Mapping ganzen Readings-Gruppen) auch eine Möglichkeit die einzelnen Readings zu remappen.
Ich hoffe, ich habe mich halbwegs verständlich ausgedrückt.
Wegen des instabilen Gateway-problems: Da bist Du nicht der einzige (siehe z.B. http://forum.mysensors.org/topic/466/ethernet-gateway-problem/86). Scheint ein Problem mit dem nRF24L01 zu sein bzw. dass die Gateway-sketches den Chip nach einem Fehler nicht neu initialisieren.
Wegen der Zuordnung beim Neustart/SensorTypen/Autocreate:
Ganz einfach ist das leider nicht. Es gibt auch SensorTypen, die senden bzw. empfangen mehrere VariablenTypen unter einer Child-Id (z.B. S_COVER) und man kann ja auch unterschiedliche SensorTypen auf einem Node mischen (wozu hat ein Arduino sonst soviele Pins...). In der Presentation-message wird auch nicht der Typ der Variablen, sondern der SensorTyp übermittelt (der in der Regel vom Zahlenwert her von den dazugehörigen VariablenTypen abweicht). Die Mappings dafür habe ich aus den Example-sketches schon zusammengesucht.
Es wäre jedenfalls mehr als sinnvoll, wenn man sich auch darauf verlassen könnte, dass alle zu einer Child-id gehörigen Readings auch sicher die gleiche Suffix hätten. Ich lass das daher erst mal mit der vom Autocreate angehängten childId, der User kann die Readings ja selber nach Gusto umbenennen.
ZitatWegen des instabilen Gateway-problems
Nur komisch, dass ich keinerlei von diesen Problemen feststellen kann...
Habe ich besseren Chip erwischt? Habe ich Glück mit den Funkverhältnissen?
ZitatEs gibt auch SensorTypen, die senden bzw. empfangen mehrere VariablenTypen unter einer Child-Id
Sowas gehört verboten ;)
Aber gut, ich sehe die Schwierigkeiten ein. Und man kann ja trotzdem alles noch nach seinem Wunsch einstellen. Sollte ich eine bahnbrechende Idee haben, melde ich mich damit ;)
Erstmal vielen Dank!
Hallo Norbert,
danke für die Info. Dann kann ich meine Bastelei mit dem Ethernet ja jetzt beenden. Ich habe es sogar noch geschafft, den ENC28J60 Sketch in einem Nano zu pumpen.
Hatte aber das gleiche Problem, Abbruch nach einigen Miinuten.
Alexander:
bei mir leuchten die LEDs ständig wenn ich die drei auf pin 7,8,9 verbinde. ich habe aber jetzt keinen passenden widerstand gefunden. Wird aber wohl nicht daran liegen.
robin
Hallo Zusammen
Ist Euch folgende Fehlermeldung bekannt ?
Can't locate Device/MySensors/Constants.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/sh$
BEGIN failed--compilation aborted at ./FHEM/00_MYSENSORS.pm line 77.
Versuch auf einem Raspi mit der aktuell eingecheckten Version.
Gruß Stefan
@Robin
Mit den LEDs ist komisch. An den Widerständen liegt es sicher nicht.
Bei mir leuchten RX und TX entsprechend beim Senden und Empfangen. Kan man sehr gut beobachten. Error-LED habe ich bis jetzt noch nicht leuchten sehen.
Irgendwas muss an deinem Aufbau falsh sein, ich habe nur leider keine Idee was.
Zitat von: Porky666 am 25 Oktober 2014, 00:53:09
Can't locate Device/MySensors/Constants.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/sh$
BEGIN failed--compilation aborted at ./FHEM/00_MYSENSORS.pm line 77.
Das besagt, dass die Constants.pm fehlt (und sicher auch Message.pm). Diese liegen nicht direkt in FHEM-Ordner, sondern in FHEM/lib/Device/MySensors
Wie hast Du die Module installiert?
Habe nur mit Update in FHEM, gesehen das die Module auftauchten.
Hab mir mal ein serielles Gateway zusammen gelötet und einen DHT22 Sensor und diese dann getestet mit serieller Konsole, das funktionierte unter Windows ganz gut, nun wollte ich die beiden mal ins FHEM einbinden.
Gruß Stefan
sind die Dateien in FHEM/lib/Device/MySensors vorhanden?
So hab aus dem Github die Dateien geholt und nun kommt das :
"00_MYSENSORS"
2014.10.25 01:26:41 1: PERL WARNING: (Missing operator before MYSENSORS?)
2014.10.25 01:26:41 1: reload: Error:Modul 00_MYSENSORS deactivated:
Unrecognized character \xC2; marked by <-- HERE after at master <-- HERE near column 50 at ./FHEM/00_MYSENSORS.pm line 13.
2014.10.25 01:26:41 0: Unrecognized character \xC2; marked by <-- HERE after at master <-- HERE near column 50 at ./FHEM/00_MYSENSORS.pm line 13.
Gruß Stefan
Du hast sicher die Dateien per Copy/Paste aus dem Browserfenster übertragen. Dabei ist die Kodierung kaputt gegangen. Lade entweder im RAW Modus, oder lade am besten den ganzen ZIP und packe gezielt die notwendigen Dateien aus.
Ne ich habe die Dateien per wget vom raspi aus gezogen.
Aber ich Schau mal das ich mir die Zip ziehe.
Danke erstmal.
Gruß
Stefan
Unrecognized character \xC2; deutet auf UTF-8 Kodierung von bestimmten Charakters. Kann schon sein, dass das mit wget auch passiert. Hast Du die RAW Links verwendet? So was wie: https://raw.githubusercontent.com/ntruchsess/fhem-mirror/master/fhem/FHEM/lib/Device/MySensors/Message.pm
Nein habe ich nicht, ich habe die File-Links aus dem Webinterface verwendet.
Nun habe ich das Git-Repo geclont und die Dateien herauskopiert und bekomme die nächste FM:
2014.10.25 01:48:33 0: Attempt to reload Device/MySensors/Constants.pm aborted.
Compilation failed in require at ./FHEM/00_MYSENSORS.pm line 78.
BEGIN failed--compilation aborted at ./FHEM/00_MYSENSORS.pm line 78.
So nach einem shutdown restart klappt es jetzt, das GW ist initialisiert, jetzt schauen wir mal ob ich meinen DHT22 auch einbinden kann.
Vielen Dank für die Hilfe.
Gruß Stefan
Datei wurde nicht (richtig) geladen. Wollte gerade Restart vorschlagen.
DHT wird schon funktionieren, habe gerade auch (mit noch weiteren Sensoren in einem Node) am Laufen.
Denk an die Inclusion ;)
Ja läuft, die Readings kommen nun an und auch in Celsius die Temperatur, das hat alles prima geklappt.
Nochmal Danke und eine angenehme Nachtruhe, ich muss mich jetzt ablegen muss Heute noch zur Spätschicht.
Gruß Stefan
Hallo Alexander,
LED: die LEDs haben auch beim Serial USB Dauerpower. Hier werden die LED an D4,5,6 angeschlossen.
Woran kann das liegen? Nochmal einen Abruf von mySensors machen?
Update (http://sourceforge.net/p/fhem/code/6806/):
- Automatisches Erzeugen der setReading/mapReading-Attribute (basierend auf den Presentation-messages beim Neustart eines Sensors). Der inclusion-mode muss dafür am Gateway aktiv sein.
EDIT:
- die Reading-namen können jetzt frei gewählt werden (autocreate legt sie zwar nach dem Schema Typ+ChildId an, aber man kann anschließend die setReading-attribute nach Gusto manuel anpassen bzw. nach der Vorlage neu setzen).
2. EDIT:
die an die per autocreate erzeugten Readings angehängte ChildId wird bei ChildId == 1 jetzt weggelassen. Damit erzeugen Nodes, die nur 1 Sensor haben die von Alex gewünschten Readings ohne angehängten Index.
- Norbert
@Robin
Die Pins 4,5 und 6 sind richtig. An dem Sketch kann es kaum liegen. Mal eine ganz blöde Frage: Hast Du die LEDs an VCC oder an GND angeschlossen? Ich habe bei mir (aus Gewohnheit) fast schon an GND gesteckt. Würde Dauerleuchten erklären.
Hallo Norbert!
Das klingt prima, vielen Dank! Ich muss jetzt erstmal weg, heute Abend teste ich alles mal durch :)
Grüße,
Alexander
Alexander,
du bist mein Held.
5V -> LED -> Pin 7,8,9
Und im Sketch die Zeile freigeben, das die optionalen LEDs benutzt werden!
Also Rolle rückwärts, wieder den alten Sketch mit dem Arduino Uno und den Ethernet-Gateway aufgebaut, wie ich in meinem Blog und im Youtube-Video beschrieben habe:
http://blog.moneybag.de/fhem-sensoren-an-fhem-mit-nrf24l01-transceiver/
LED 8 flackert nur kurzzeitig, wenn ein Signal vom Sensor empfangen wurde.
robin
Hallo Norbert,
das autocreate funktioniert supi!! (getestet mit Relay) Vielen Dank fuer die Implementierung!!
Repaeter-Mode und Protokoll-Version wird auch erkannt und in den internals + attributes gesetzt - das laesst keine Wuensche offen :-)
Vielen Dank!!
Mir ist noch was aufgefallen bzgl. den Attribute requestAck.
Das geht bei mir in eine Endlosschleife (s.u.).
Reproduzieren kann ich das, wenn ich das Attrbiute setze
fhem:> attr gateway requestAck 1
und anschliessend einen Node einschalte.
dann wird gateway=>internals=>outstandingAck = 1
Beeenden laesst sich dieser Endlosloop nur indem man den requestAck wieder loescht.
fhem:> delattr gateway requestAck
Auszug aus dem logfile:
2014.10.25 20:28:09 5: MYSENSORS Read: Rx: fr=001 ci=255 c=003(C_INTERNAL ) st=006(I_CONFIG ) ack=0 '0'
2014.10.25 20:28:09 5: MYSENSORS send: Rx: fr=001 ci=255 c=003(C_INTERNAL ) st=006(I_CONFIG ) ack=1 'M'
----- anfang Endlosschleife
2014.10.25 20:28:09 5: SW: 313b3235353b333b313b363b4d0a
2014.10.25 20:28:09 4: MYSENSORS_DEVICE MYSENSOR_1: respond to config-request
2014.10.25 20:28:09 5: MYSENSORS/RAW: /0;0;3;0;9
2014.10.25 20:28:09 5: MYSENSORS/RAW: 0;0;3;0;9/;send: 0-0-1
2014.10.25 20:28:09 5: MYSENSORS/RAW: 0;0;3;0;9;send: 0-0-1/-1 s=255,c=
2014.10.25 20:28:09 5: MYSENSORS/RAW: 0;0;3;0;9;send: 0-0-1-1 s=255,c=/3,t=6,pt=0,l
2014.10.25 20:28:09 5: MYSENSORS/RAW: 0;0;3;0;9;send: 0-0-1-1 s=255,c=3,t=6,pt=0,l/=1,st=ok:M
2014.10.25 20:28:09 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'send: 0-0-1-1 s=255,c=3,t=6,pt=0,l=1,st=ok:M'
2014.10.25 20:28:09 5: MYSENSORS gateway gateway: send: 0-0-1-1 s=255,c=3,t=6,pt=0,l=1,st=ok:M
2014.10.25 20:28:09 5: MYSENSORS/RAW: /0;0;3;0;9
2014.10.25 20:28:09 5: MYSENSORS/RAW: 0;0;3;0;9/;read: 1-1-0
2014.10.25 20:28:09 5: MYSENSORS/RAW: 0;0;3;0;9;read: 1-1-0/ s=255,c=3,
2014.10.25 20:28:09 5: MYSENSORS/RAW: 0;0;3;0;9;read: 1-1-0 s=255,c=3,/t=6,pt=0,l=1
2014.10.25 20:28:09 5: MYSENSORS/RAW: 0;0;3;0;9;read: 1-1-0 s=255,c=3,t=6,pt=0,l=1/:M
1;255;
2014.10.25 20:28:09 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'read: 1-1-0 s=255,c=3,t=6,pt=0,l=1:M'
2014.10.25 20:28:09 5: MYSENSORS gateway gateway: read: 1-1-0 s=255,c=3,t=6,pt=0,l=1:M
2014.10.25 20:28:09 5: MYSENSORS/RAW: 1;255;/3;1;6;M
2014.10.25 20:28:09 5: MYSENSORS Read: Rx: fr=001 ci=255 c=003(C_INTERNAL ) st=006(I_CONFIG ) ack=1 'M'
2014.10.25 20:28:09 5: MYSENSORS send: Rx: fr=001 ci=255 c=003(C_INTERNAL ) st=006(I_CONFIG ) ack=1 'M'
----- ende Endlosschleife
Die Zeilen zwischen anfang- und ende-Endlosschleife kommen pro Sekunde ca. 40x
Zitat von: fh168 am 25 Oktober 2014, 16:22:29
LED 8 flackert nur kurzzeitig, wenn ein Signal vom Sensor empfangen wurde.
Prima, so ist das bei mir auch.
Hi,
ich wollte mal fragen, ob mit MySensors auch die Sensoren von GrovePi:
http://www.element14.com/community/thread/30023/l/grovepi-for-the-raspberry-pi
bzw.
http://ras-pi.de/2014/09/grovepi/
als Sensoren in FHEM eingelesen werden können?
Oder ob es irgendwie anders geht?
Gruß
Bracew
Hallo Norbert,
ich habe mein bestehendes Node gelöscht, neue Version aus SVN geholt und meinen Sensor neu angelernt. Interesanterweise hat das nicht gleich funktioniert und ich musste mehrfach Inclusion-Mode starten und den Sensor resetten bevor alles angelegt wurde. Ob das daran liegt, das mein Testsensor mitlerweile vier verschiedene Werte liefert?
Danach war jedoch alles perfekt angelegt. Fast. Eine Kleinigkeit habe ich doch (sorry, Berufskrankheit ;) )
Die Readings für Temperatur und Luftfeuchte hießen entsprechend. Die für Distance und Lichtstärke waren jedoch mit ihrer ID angelegt. Durch die Änderung der Attibute war das gleich erledigt, ein wenig inkonsequent ist das aber schon.
Wie dem auch sei, ich finde die derzeitige Funktionalität praktisch perfekt :) Vielen Dank!
Ach ja, kriegt man dür den Relay irgendwie auch 'toggle' hin? (brauche ich zwar nicht, aber vollständigkeitshalber)
Grüße,
Alexander
Zitat von: Bracew am 25 Oktober 2014, 22:01:22
ich wollte mal fragen, ob mit MySensors auch die Sensoren von GrovePi:
Beim kurzen Blick scheinen diese Dinger nichts mit MySensor zu tun zu haben. Sind auch gar nicht Funk-basiert.
Zitat von: Bracew am 25 Oktober 2014, 22:01:22
als Sensoren in FHEM eingelesen werden können?
Bestimmt, man braucht halt ein entsprechendes Modul. Wenn es bis jetzt keinen gibt, kannst ja (in einem neuen Thread) das System den Entwicklern schmackhaft machen. Mit MySynsors hat es ja wunderbar funktioniert ;)
Grüße,
Alexander
OK, siehe:
http://forum.fhem.de/index.php/topic,28286.0.html
Zitat von: eni am 25 Oktober 2014, 21:02:54
Mir ist noch was aufgefallen bzgl. den Attribute requestAck.
Das geht bei mir in eine Endlosschleife (s.u.).
Ist mir bekannt. Bisher ist das noch sehr simpel implementiert. Wenn requestAck gesetzt ist, dann wird einfach an jedes ausgehende Packet das Requet-ack-flag gesetzt, das Packet zwischengespeichert und auf eine Acknowledge-antwort (das ist im Prinzip das selbe Packet) gewartet. Kommt nix, wird das Packet jede Sekunde (potentiell endlos) wieder transmittet. Das ist zum einen noch nicht wirklich schlau (z.B. sollten die zeitlichen Abstände immer größer werden und das Packet irgendwann verworfen werden, wärend ein Fehler-reading gesetzt wird).
Leider werden manche Packete (z.B. die Antwort auf den Config-request) systematisch nicht wie erwartet acknowledged. Diese Packet-arten dürfen dann outbound auch kein Request-ack-flag bekommen.
Wird demnächst überarbeitet.
- Norbert
Zitat von: hexenmeister am 25 Oktober 2014, 22:01:55
Die Readings für Temperatur und Luftfeuchte hießen entsprechend. Die für Distance und Lichtstärke waren jedoch mit ihrer ID angelegt. Durch die Änderung der Attibute war das gleich erledigt, ein wenig inkonsequent ist das aber schon.
Irgendwie ist das dämlich. Der Sketch mit dem ich teste verwendet die 1 als kleinste ChildId, daher habe teste ich auf > 1 und hänge dann die ChildId zur Sicherstellung der Eindeutigkeit an. Jetzt verwendet Dein Sketch auch die 0 :-(
Prinzipiell könnte man die Readingsnummern auch nur dann hochzählen, wenn beim Eintreffen der Presentation-messages für den entsprechenden Typ schon mapReading-attribute definiert sind. Nur haben dann potentiell nicht alle zu einer ChildId gehörigen Readings die selbe Nummer (wäre wohl auch verwirrend).
- Norbert
Ich habe mein Sketch zwas mittlerweile etwas umgebaut (jetzt auch noch mit einem PIR), aber die 0 habe ich nicht ausgedacht, stand schon so im Humidity-Sketch. Scheinbar gibt es hier keine Vorgaben :(
ZitatNur haben dann potentiell nicht alle zu einer ChildId gehörigen Readings die selbe Nummer (wäre wohl auch verwirrend).
Ist so verwirrend, dass ich das nicht verstanden habe. :) Ich glaube, ich muss das morgen noch mal lesen ;)
Insgesamt ist das alles noch Feintuning, grundsätzlich funktioniert alles schon sehr gut!
(OK, die Sache mit ACK-Wiederholung halte ich noch für wichtig.)
Die Idee mit den drei zusätzlichen LEDs zur Statusanzeige auf dem Gateway ist schon klasse.
Die Stabiltität mit einem Uno und dem W5100 Netzwerk-Shield klappt jetzt auch, zumindest ist der jetzt 10 Stunden ohne Unterbrechungen durchgelaufen.
Wie sieht es nach einem Update oder einer Strom-/ Netzwerkunterbrechung aus?
Ein einfaches shutdown restart funktioniert nicht. Die LEDs bleiben dunkel. Beim Klick auf dem externen inclusion-Button blinkt die LED ungefähr eine Minute, genauso wenn man über Fhem manuell über set gateway inclusion-mode on setzt.
ich helfe mir derzeitig, das ich die einzelnen Sensoren (ich habe testweise mal drei zusammengeklöppelt) resette, dann fängt das LED-Farbenspiel und Geblinke vom Gateway wieder an.
Das kann aber nicht sein, wenn man 20 Sensoren später im Haus verteilt hat.
update: ich wollte gerade einen neuen Sensor anlernen, klicke in der Software auf inclusion mode
root@raspbmc:/opt/fhem# Use of uninitialized value in anonymous hash ({}) at ./FHEM/10_MYSENSORS_DEVICE.pm line 170, <$fh> line 2097.
Use of uninitialized value in anonymous hash ({}) at ./FHEM/10_MYSENSORS_DEVICE.pm line 170, <$fh> line 2097.
Use of uninitialized value in anonymous hash ({}) at ./FHEM/10_MYSENSORS_DEVICE.pm line 170, <$fh> line 2097.
Use of uninitialized value in anonymous hash ({}) at ./FHEM/10_MYSENSORS_DEVICE.pm line 170, <$fh> line 2100.
Use of uninitialized value in anonymous hash ({}) at ./FHEM/10_MYSENSORS_DEVICE.pm line 170, <$fh> line 2100.
Use of uninitialized value in anonymous hash ({}) at ./FHEM/10_MYSENSORS_DEVICE.pm line 170, <$fh> line 2100.
Use of uninitialized value in anonymous hash ({}) at ./FHEM/10_MYSENSORS_DEVICE.pm line 170, <$fh> line 2120.
Use of uninitialized value in anonymous hash ({}) at ./FHEM/10_MYSENSORS_DEVICE.pm line 170, <$fh> line 2120.
Use of uninitialized value in anonymous hash ({}) at ./FHEM/10_MYSENSORS_DEVICE.pm line 170, <$fh> line 2120.
Undefined subroutine &MYSENSORS::DEVICE::ReadingsVal called at ./FHEM/10_MYSENSORS_DEVICE.pm line 414.
Kann man eigentlich das so programmieren, das bei Temperatur / Luftfeuchtigkeitssensoren in den Readings
state T: 12.6 H: 75 2014-10-26 19:14:51
herauskommt, damit man nur eine Zeile wegschreiben muss?
robin
Hallo Zusammen,
da ich die Mysensor Nodes mit Batterie betreibe, habe ich natürlich auch ein Bedarf ein Reading oder 2 mit dem Batterielevel empfangen zu können.
Nun auf [url]http://mysensors.org/build/battery[url] gibt es den Hinweis mit einem einfachen Spannungsteiler über einen Analogen Eingang (A0) die Spannung zu überwachen.
Ich habe das dort verlinkte Batterysensor.ino von Github mal mit dem Humiditysensor.ino gemergt -- aufgespielt und getestet.
Funktioniert mit deinem im FHEM ankommenden Reading Batterylevel als % Angabe. Das kann man auch varirieren mit Battery in Volt oder beides. Vielleicht passts Euch ja.
#include <SPI.h>
#include <MySensor.h>
#include <DHT.h>
#define CHILD_ID_HUM 0
#define CHILD_ID_TEMP 1
int BATTERY_SENSE_PIN = A0;
#define HUMIDITY_SENSOR_DIGITAL_PIN 3
unsigned long SLEEP_TIME = 900000; // Sleep time between reads (in milliseconds)
int oldBatteryPcnt = 0;
MySensor gw;
DHT dht;
float lastTemp;
float lastHum;
boolean metric = true;
MyMessage msgHum(CHILD_ID_HUM, V_HUM);
MyMessage msgTemp(CHILD_ID_TEMP, V_TEMP);
void setup()
{
analogReference(INTERNAL);
gw.begin();
dht.setup(HUMIDITY_SENSOR_DIGITAL_PIN);
// Send the Sketch Version Information to the Gateway
gw.sendSketchInfo("Humidity", "1.0");
// Register all sensors to gw (they will be created as child devices)
gw.present(CHILD_ID_HUM, S_HUM);
gw.present(CHILD_ID_TEMP, S_TEMP);
metric = gw.getConfig().isMetric;
}
void loop()
{
delay(dht.getMinimumSamplingPeriod());
float temperature = dht.getTemperature();
if (isnan(temperature)) {
Serial.println("Failed reading temperature from DHT");
} else if (temperature != lastTemp) {
lastTemp = temperature;
if (!metric) {
temperature = dht.toFahrenheit(temperature);
}
gw.send(msgTemp.set(temperature, 1));
Serial.print("T: ");
Serial.println(temperature);
}
float humidity = dht.getHumidity();
if (isnan(humidity)) {
Serial.println("Failed reading humidity from DHT");
} else if (humidity != lastHum) {
lastHum = humidity;
gw.send(msgHum.set(humidity, 1));
Serial.print("H: ");
Serial.println(humidity);
}
{
// get the battery Voltage
int sensorValue = analogRead(BATTERY_SENSE_PIN);
Serial.println(sensorValue);
// 1M, 470K divider across battery and using internal ADC ref of 1.1V
// Sense point is bypassed with 0.1 uF cap to reduce noise at that point
// ((1e6+470e3)/470e3)*1.1 = Vmax = 3.44 Volts
// 3.44/1023 = Volts per bit = 0.003363075
float batteryV = sensorValue * 0.003363075;
int batteryPcnt = sensorValue / 10;
Serial.print("Battery Voltage: ");
Serial.print(batteryV);
Serial.println(" V");
Serial.print("Battery percent: ");
Serial.print(batteryPcnt);
Serial.println(" %");
if (oldBatteryPcnt != batteryPcnt) {
// Power up radio after sleep
gw.sendBatteryLevel(batteryPcnt);
oldBatteryPcnt = batteryPcnt;
}
gw.sleep(SLEEP_TIME); //sleep a bit
}}
Gruß
Stefan und Danke für die Prima Arbeit an dem Modul !
Hallo Stefan,
probiere ich aus.
Mir ist auch aufgefallen, das Sketch mit dem Temperatursensor (DS18B20) ziemlich stark an der Batterie nuckelt, ich glaub daran muss man noch arbeiten.
Wie sieht es bei Euren Sensoren aus?
Hier im Forum http://mysensors.org/build/binary (weiter unten) hat jemand den Sleep-Modus verbessert.
LG
/robin
Hallo alle zusammen :-)
melde mich aus meinen Urlaub zurück.
Hier hat sich ja eine ganze Menge getan. Ich bin schon feste am lesen, damit ich auf den aktuellen Stand komme ;D
Gruß Jens
melde mich auch aus dem (Kurz-)Urlaub zurück...
Zitat von: fh168 am 26 Oktober 2014, 09:01:53
Wie sieht es nach einem Update oder einer Strom-/ Netzwerkunterbrechung aus?
Ein einfaches shutdown restart funktioniert nicht.
Reconnect bei als TCP-server arbeitenden Devices ist problematisch, wenn man das Device einfach so neustartet oder ausschaltet. Das bekommt die Gegenstelle (FHEM bzw. 00_MYSENSORS.pm) nämlich gar nicht unmittelbar mit, sondern erst wenn FHEM selber Daten schicken will und die TCP-timeouts ablaufen (das dauert etliche Minuten und wenn 00_MYSENSORS.pm nichts schicken will, merkt es den Verbindungsverlust überhaupt nicht). Eventuell könnte man die I_VERSION C_INTERNAL-message als Heartbeat misbrauchen um mitzukriegen, wenn die Verbindung weg ist, bisher ist so eine Funktion jedenfalls noch nicht eingebaut.
Ein 'shutdown restart' sollte eigentlich die Verbindung neu aufbauen. Damit das zuverlässig vom Arduino erkannt wird, muss man den EthernetGateway-sketch wohl noch etwas überarbeiten - der verläßt sich nämlich zu 100% auf 'EthernetServer::available()' ohne jemals stop() an einem Client-objekt aufzurufen. Wenn da die 4 verfügbaren Sockets 'verbraucht' sind, dann war's das erst mal (bis der WIZ5100-chip die sockets selbsttätig per timeout schließt, was eben auch etwas länger dauern kann).
Zitat von: fh168 am 26 Oktober 2014, 09:01:53
update: ich wollte gerade einen neuen Sensor anlernen, klicke in der Software auf inclusion mode
root@raspbmc:/opt/fhem# Use of uninitialized value in anonymous hash ({}) at ./FHEM/10_MYSENSORS_DEVICE.pm line 170, <$fh> line 2097.
Use of uninitialized value in anonymous hash ({}) at ./FHEM/10_MYSENSORS_DEVICE.pm line 170, <$fh> line 2097.
sieht nach nicht aktualisierter FHEM/lib/Device/MySensors/Constants.pm aus. Die Dateien in 'lib' kommen leider per update (noch nicht) mit.
Zitat von: fh168 am 26 Oktober 2014, 09:01:53
Kann man eigentlich das so programmieren, das bei Temperatur / Luftfeuchtigkeitssensoren in den Readings
state T: 12.6 H: 75 2014-10-26 19:14:51
herauskommt, damit man nur eine Zeile wegschreiben muss?
ja, kannst Du mit userReadings (http://fhem.de/commandref.html#userReadings) machen.
Hallo,
Habe mal ein Node mit 8 Relais gebastelt und eingebunden,
um nun die Relais zu schalten muss ich set Befehle senden,
Besteht die Möglichkeit dieses über webcmd zu schalten, oder muss ich dummys für jedes Relais anlegen.
Gruß
Stefan
so ich habe mal die usb/serielle Version an den Start gebracht :-)
define MYS_GW MYSENSORS /dev/ttyUSB1@115200
attr MYS_GW stateFormat connection
attr MYS_GW verbose 5
Logfile sagt:
2014.10.31 18:15:56 3: Opening MYS_GW device /dev/ttyUSB1
2014.10.31 18:15:56 3: Setting MYS_GW baudrate to 115200
2014.10.31 18:15:56 3: MYS_GW device opened
Also alles fein :D
Dann den 1. Sensor ins Spiel gebracht
define mys_Temperatur1 MYSENSORS_DEVICE 60
attr mys_Temperatur1 IODev MYS_GW
attr mys_Temperatur1 stateFormat V_TEMP
#attr mys_Temperatur1 subscribeReading_state MYSENSORS/60/0/V_TEMP
attr mys_Temperatur1 room MySensors-Test
attr mys_Temperatur1 verbose 5
bekomme aber keine Werte (Gegentest am MQTT Gateway alles io).
Was fehlt oder mache ich falsch?
Hallo Jens,
ich kann dir nur von mir berichten, ein State bekomme ich auch nicht.
Hast du denn den Sensor per autocreate anlegen lassen?
Also das GW mit inclusion 1 auf autocreate gesetzt ?
Gruß
Stefan
Nein, ich habe ihn per Hand angelegt.
Bekomme aber auf der Linux Console
2014.10.31 19:13:16 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'read: 60-60-0 s=0,c=1,t=0,pt=7,l=5:25.5'
2014.10.31 19:13:16 5: MYSENSORS gateway MYS_GW: read: 60-60-0 s=0,c=1,t=0,pt=7,l=5:25.5
2014.10.31 19:13:16 5: MYSENSORS Read: Rx: fr=060 ci=000 c=001(C_SET ) st=000(V_TEMP ) ack=0 '25.5'
2014.10.31 19:13:16 4: MYSENSORS_DEVICE mys_Temperatur1: ignoring C_SET-message no reading-mapping for childId 0, type temperature
2014.10.31 19:13:16 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'read: 60-60-0 s=1,c=1,t=0,pt=7,l=5:25.5'
2014.10.31 19:13:16 5: MYSENSORS gateway MYS_GW: read: 60-60-0 s=1,c=1,t=0,pt=7,l=5:25.5
2014.10.31 19:13:16 5: MYSENSORS Read: Rx: fr=060 ci=001 c=001(C_SET ) st=000(V_TEMP ) ack=0 '25.5'
2014.10.31 19:13:16 4: MYSENSORS_DEVICE mys_Temperatur1: ignoring C_SET-message no reading-mapping for childId 1, type temperature
2014.10.31 19:14:53 5: MYSENSORS/RAW: /0;0;3
2014.10.31 19:14:53 5: MYSENSORS/RAW: 0;0;3/;0;9;read: 60-60-0 s=1,c=1,t=0,pt=7,l=5:25.4
60;1;1;0;0;25.4
2014.10.31 19:14:53 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'read: 60-60-0 s=1,c=1,t=0,pt=7,l=5:25.4'
2014.10.31 19:14:53 5: MYSENSORS gateway MYS_GW: read: 60-60-0 s=1,c=1,t=0,pt=7,l=5:25.4
2014.10.31 19:14:53 5: MYSENSORS Read: Rx: fr=060 ci=001 c=001(C_SET ) st=000(V_TEMP ) ack=0 '25.4'
2014.10.31 19:14:53 4: MYSENSORS_DEVICE mys_Temperatur1: ignoring C_SET-message no reading-mapping for childId 1, type temperature
2014.10.31 19:15:25 5: MYSENSORS/RAW: /0;0;3;0;9;read
2014.10.31 19:15:25 5: MYSENSORS/RAW: 0;0;3;0;9;read/: 60-60-0 s=1,c=1,t=0,pt=7,l=5:25.5
60;1;1;0;0;25.5
Inclusion Mode am Gateway (Hardwareseitig hatte ich ausgeführt) aber automatisch im FHEM ist nichts passiert.
Muss man da für das Autocreate noch etwas setzen, es wurde noch nie was bei mir automatisch angelegt obwohl in der fhem.cfg
define autocreate autocreate
attr autocreate filelog ./log/%NAME-%Y.log
steht. Ich sehe gerade (nach Raspi-Neustart) kommen die Meldungen jetzt auch im FHE;-Log rein, aber der Wert wird trotzdem nicht angezeigt (siehe log 25.4 Grad)
Ich denke das es mit der Meldung
MYSENSORS_DEVICE mys_Temperatur1: ignoring C_SET-message no reading-mapping for childId 1, type temperature
zu tun hat, das ich noch was vergessen habe.
Gruß Jens
Sieht jetzt bei mir so aus.
Bei mir siehts so aus, mit Inclusion button gedrückt und dann auf Reset vom Sensor geklickt.
Die Readings haben sich selber erzeugt.
jupps, danke 8)
habe es jetzt hinbekommen, ich habe es jetzt nach "Stefan's" Vorschlag gemacht.
Aber mal eine ganz dumme Frage ::) wie kann man die per "autocreate" angelegten Devices in seine cfg übernehmen?
Zitat von: fh555 am 31 Oktober 2014, 20:07:38wie kann man die per "autocreate" angelegten Devices in seine cfg übernehmen?
im Webfrontend links oben auf 'Save config' klicken.
Zitat von: fh555 am 31 Oktober 2014, 20:07:38
wie kann man die per "autocreate" angelegten Devices in seine cfg übernehmen?
Speichern? ;)
@ntruchsess
Danke, hatte ich noch NIE genutzt.
@hexenmeister
Das war ja die Frage.
Ich hatte entweder immer Änderungen per ssh auf der Linux-Console direkt oder beim Webfrontend das
"save fhem.cfg" bzw. "save as" genutzt und da werden die Sachen von "autocreate" NICHT abgespeichert!
Gruß Jens
warum nicht einfach "save"? hat bei mir immer tadellos funktioniert.
und noch eine kleine Frage ???
Ich habe noch ein Problem mit der Zuordnung des invertierten Wertes.
Wie ihr ja auch schon probiert hattet, habe ich das Problem mit einen Schalter, welcher im Aus eine 1 und im Ein eine 0 liefert (Binary Switch).
Jetzt hatte ich lt. Forum und auch lt. Hilfe "Device specific help" folgendes Beispiel versucht.
attr <name> mapReadingType_<reading> <new reading name> [<value>:<mappedvalue>]*
configures reading type names that should be used instead of technical names
E.g.: attr xxx mapReadingType_LIGHT switch 0:on 1:off to be used for mysensor Variabletypes that have no predefined defaults (yet)
define MYSENSOR_10 MYSENSORS_DEVICE 10
attr MYSENSOR_10 IODev MYS_GW
attr MYSENSOR_10 devStateIcon .*:on .*:off
attr MYSENSOR_10 mapReadingType_tripped3 switch 0:on 1:off
attr MYSENSOR_10 mapReading_tripped3 3 tripped
attr MYSENSOR_10 mode node
attr MYSENSOR_10 room MySensors
attr MYSENSOR_10 stateFormat switch
attr MYSENSOR_10 version 1.4
im State steht aber nur "switch" und nicht der Wert "on" oder "off"
Was mache ich schon wieder falsch? :'(
Hallo,
Im Sketch kannst du angeben wann er eine 0 oder eine 1 annehmen soll.
Gruß
Stefan
#define Relay_on 0
#define Relay_off 1
Hi Stefan,
du meinst bestimmt ein Relay-Sketch (der kommt bei mir erst als nächstes), ich meinte aber den "normalen" "Funkschalter".
Wenn man halt in der Weboberfläche oder dann bei der Ausführung von Aktionen eine 1 (für Aus) sieht, denkt man im Normalfall, dass das Gerät (in meinen Fall der Schalter) betätigt ist, also EIN, was aber nicht stimmt. Deshalb würde ich es halt vorziehen auch bei einen normalen Schalter den Zustand "on" bzw. "off" zu sehen und mit diesen Variablen arbeiten, natürlich richtig zugeordnet 0:on und 1:off.
Gruß Jens
keiner eine Idee, oder geht es momentan nicht, weil es im MySensors-Modul nicht vorgesehen ist?
Gruß jens
attr MYSENSOR_10 mapReadingType_LIGHT switch 0:on 1:off
'LIGHT' bezieht sich auf die MySensors-konstante 'V_LIGHT' (siehe lib/Device/MySensors/Constants.pm (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/lib/Device/MySensors/Constants.pm#L22)) ohne das Präfix 'V_'.
Damit kann man die Default-mappings (wie sie in der 10_MYSENSORS_DEVICE.pm (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/10_MYSENSORS_DEVICE.pm#L111) vordefiniert sind) überschreiben.
Das Attribut ist zugegebenerweise nicht wirklich Endusertauglich, weil man sowohl die Konstantennamen als auch die möglichen Werte nur aus dem Sourcecode entnehmen kann. Dafür kann man allerdings auch in seinen Sketch schauen, die Konstantennamen sind da ja die gleichen.
Vieileicht ergänge ich ja an das mapReading_XXX-attribut noch um optionale Parameter um das Mapping direkt am Attribut vorzunehmen. Wäre vermutlich besser verständlich.
Gruß,
Norbert
Hallo ntruchsess,
wie kann ich es aber mit tripped machen? Geht es überhaupt?
In der https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/10_MYSENSORS_DEVICE.pm#L111 (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/10_MYSENSORS_DEVICE.pm#L111)
Zeile 115
gibt es ja die variable V_LIGHT => { type => "switch", val => { 0 => 'off', 1 => 'on' }}
aber bei Zeile 134 nur V_TRIPPED => { type => "tripped" }?
Gruß Jens
für 'tripped' ist mir kein sinnvolles mapping eingefallen. Was soll da hin? 'active','shutdown','armed','blown','enabled'... ?
den Default kannst du jedenfalls einfach überschreiben:
attr MYSENSOR_10 mapReadingType_TRIPPED tripped 0:hugo 1:helga
Hallo Norbert,
das Modul funktioniert bei mir jetzt relativ stabil. Vielen Dank fuer diese super Implementierung!!
Drei Dinge sind mir noch aufgefallen:
1) wenn ein MYSENSORS nicht connected ist, kann man es mit "delete gateway" nicht loeschen.
das braucht ich manchmal, wenn ich das gateway ein-/ausschalte, dann bekommt es ein anderes Device /dev/ttyUSB1 anstatt /dev/ttyUSB0.
dann bekomme ich das "alte" das mit /dev/ttyUSB0 arbeitet nicht geloescht. Anlegen des neuen mit /dev/ttyUSB1 funktioniert.
2) ich bekomme folgende Fehler: (Version fhem-code-6810-trunk)
Undefined subroutine &MYSENSORS::DEVICE::ReadingsVal called at ./FHEM/10_MYSENSORS_DEVICE.pm line 414.
3) Zum Thema Acknoledge - das funktioniert auch - ist der Node weg geht die Anzahl der outstandingAck hoch, sobald der Node wieder erreichbar ist, werden diese wieder abgarbeitet und gehen auf 1. Der einzige der stehenbleibt ist die Antwort vom I_CONFIG - Request.
014.10.25 20:28:09 5: MYSENSORS Read: Rx: fr=001 ci=255 c=003(C_INTERNAL ) st=006(I_CONFIG ) ack=1 'M'
2014.10.25 20:28:09 5: MYSENSORS send: Rx: fr=001 ci=255 c=003(C_INTERNAL ) st=006(I_CONFIG ) ack=1 'M'
siehe http://forum.fhem.de/index.php?action=post;quote=211622;topic=26807.165;last_msg=214847
... hoffentlich kommt das nicht zu meckerig rueber.
die Mysensors-fhem-module sind wirklich klasse, und machen sehr viel freude, da funktionier und gut zu bedienen :-)
viele gruesse
enrico
Hallo ntruchsess,
Zitat von: ntruchsess am 04 November 2014, 09:41:23
für 'tripped' ist mir kein sinnvolles mapping eingefallen. Was soll da hin? 'active','shutdown','armed','blown','enabled'... ?
den Default kannst du jedenfalls einfach überschreiben:
attr MYSENSOR_10 mapReadingType_TRIPPED tripped 0:hugo 1:helga
Warum nicht einfach "on" "off", wie du ja schon sagst, Überschreiben kann man es doch dann wie man will, wenn die Variable definiert ist.
Ich habe mal bei mir die MySensors_DEVICE.pm angepasst.
V_TRIPPED => { type => "tripped" , val => { 0 => 'on', 1 => 'off' }}Jetzt geht es wie gewünscht :-)
Readings tripped3 off 2014-11-04 21:39:09wird aber beim nächsten Update überschrieben :-(
Gruß Jens
updates:
- Mapping optional direkt am mapReading-attribut (http://sourceforge.net/p/fhem/code/6886/) überschreiben:
attr node mapReading_schalter 1 switch 0:on,1:off
- Funktion von attr requestAck (http://sourceforge.net/p/fhem/code/6887/) überarbeitet. Erhöht jetzt das Intervall mit jedem weiteren Zustellversuch, ignoriert Acknowledges von CONFIG-messages.
- Default-values 0:off,1:on für V_TRIPPED (http://sourceforge.net/p/fhem/code/6888/)
Gruß,
Norbert
Hallo,
ich kämpfe seit paar Tagen mit dem MySensors-Modul und FHEM. Ich habe den serial Gateway an den Raspi angeschlossen und einen Temp-Sensor per Funk verbunden.
Im Logfile von FHEM sehe ich auch die übertragene Temperatur aber ich bekomme die nicht ins FHEM angezeigt.
Auszug Log:
2014.11.05 22:12:41 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'read: 100-100-0 s=0,c=1,t=0,pt=7,l=5:21.4'
2014.11.05 22:12:41 5: MYSENSORS gateway MYS_GW: read: 100-100-0 s=0,c=1,t=0,pt=7,l=5:21.4
2014.11.05 22:12:41 5: MYSENSORS/RAW: 100;/0;1;0;0;21.4
2014.11.05 22:12:41 5: MYSENSORS Read: Rx: fr=100 ci=000 c=001(C_SET ) st=000(V_TEMP ) ack=0 '21.4'
2014.11.05 22:13:16 5: MYSENSORS/RAW: /0;0;3;0;9;read: 100-100-0 s=0,c=1,t=0,pt=7,l=
2014.11.05 22:13:16 5: MYSENSORS/RAW: 0;0;3;0;9;read: 100-100-0 s=0,c=1,t=0,pt=7,l=/5:21.5
100;0;1;0;0;21.5
Der Eintrag in die fhem.cfg sieht so aus:
define MYS_GW MYSENSORS /dev/ttyACM1@115200
attr MYS_GW stateFormat connection
attr MYS_GW verbose 5
define MYSENSOR_100 MYSENSORS_DEVICE 100
attr MYSENSOR_100 IODev MYS_GW
attr MYSENSOR_100 mode node
attr MYSENSOR_100 mapReading_temperature 0 temperature
attr MYSENSOR_100 version 1.4.1
Den Gateway habe ich eingefügt den Sensor "autocreate".
Nun möchte ich die Temp auf der Startseite angezeigt bekommen vlt. sogar in einem Plot.
Ich bekomms einfach nicht hin.
Ich benutze die aktuelle Version von MySensors 1.4 und auch die aktuelle Version vom MySensors.pm Modul.
Wo kann der Fehler liegen?
Vielen Denk schon im vorraus.
Viele Grüsse
Bobby
Hi Norbert,
danke, ihr habt bei der Umsetzung und Implentierung von MySensors wirklich eine super Arbeitet geleistet "Respekt" 8)
Gruß Jens
Zitat von: BobbyD am 05 November 2014, 22:21:12
Nun möchte ich die Temp auf der Startseite angezeigt bekommen
->
attr MYSENSOR_100 stateFormat temperature
Guten Morgen,
vielen Dank schon mal.
Ich habe das so eingetragen in die fhem.cfg. Jetzt steht in der Übersicht bei "MYSENSORS_DEVICE " und "MYSENSOR_100" das Wort "temperature" drin aber noch nicht der Wert ?
Bei der Variable "STATE" sind jetzt auch die Fragezeichen sind weg und dafür steht auch das Wort "temperature" drin.
Leider habe ich noch nicht herausbekommen wie man hier im Forum Bilder einfügt.
Irgendwie komm ich nicht so recht weiter.
Bobby
seit dem letzten Update von gestern funktioniert mein Feuchtigkeits / Temperatur humidity-Sensor nicht mehr. Gateway-Lan
seit gestern funktioniert bei mir mein Temperatursensor auch nicht mehr :(
Am Gateway kommt die Message rein, wird aber nicht verarbeitet.
Ich habe den Sensor heute nach dem heutigen Update noch einmal neu anlegen lassen aber das Problem besteht immernoch.
und das steht im log
2014.11.07 00:19:26 5: MYSENSORS/RAW: 0/;0;3;0;9;read: 60-60-0 s=0,c=1,t=0,pt=7,l=5:26.6
60;0;1;0;0;26.6
2014.11.07 00:19:26 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'read: 60-60-0 s=0,c=1,t=0,pt=7,l=5:26.6'
2014.11.07 00:19:26 5: MYSENSORS gateway MYS_GW: read: 60-60-0 s=0,c=1,t=0,pt=7,l=5:26.6
2014.11.07 00:19:26 5: MYSENSORS Read: Rx: fr=060 ci=000 c=001(C_SET ) st=000(V_TEMP ) ack=0 '26.6'
Das was also fehlt, ist der Reading Eintrag. Vielleicht ist das auch der Grund, warum "BobbyD" bald verzweifelt :-)
Gruß Jens
P.S.: Ein "set" oder eine Auswertung per "Alias" scheint auch nicht zu funktionieren, aber erst einmal eins nach den anderen ::)
Ich hab mir noch keinen Temperatursensor gebaut und konnte nur mit einem BinarySwichSensor testen. Der Unterschied ist, dass der definierte values (0 und 1) hat, die auch in den Typemappings drinstehen, ein Temperatursensor hat die nicht. Stell doch bitte mal 'attr MYSENSOR_60 verbose 5' an, damit man die Logausgaben des Devices selbst sieht.
Weil der reconnect mit dem EthernetGateway alles andere als zuverlässig war habe ich mich dem mal angenommen und den code dahingehend überarbeitet: EthernetGateway.ino (https://github.com/ntruchsess/MySensors/raw/ethernet_gw/libraries/MySensors/examples/EthernetGateway/EthernetGateway.ino)
Arbeitet jetzt so, dass beim Neu-verbinden die bisherige Verbindung sauber aufgeräumt wird. Funktioniert ab Arduino-IDE >= 1.0.6 bzw. 1.5.7. (Darunter fehlt die passende Implementierung des Operators '==' beim EthernetClient, ist ein Change, den ich vor ca. 6 Monaten mal zum Arduino-projekt contributed habe ;-)).
- Norbert
Hi ntruchsess,
das log bringt mit verbose 5 folgendes zu Tage:
2014.11.07 18:10:32 4: MYSENSORS_DEVICE MYSENSOR_60: ignoring C_SET-message not type-mapping for type V_TEMP
Es hat ja schon ein ganze Zeit funktioniert, erst als du die Sache mit Tripped eingefuegt hast (glaube ich), ging es nicht mehr.
Evtl. hast du ja zu diesen Zeitpunkt noch mehr geaendert?
Gruss Jens
danke für die Fehlermeldung, hilft mir weiter.
Ja klar habe ich da noch mehr geändert: man kann beim mapReading-attribut jetzt (optional) das value-mapping direkt überschreiben:
attr MYSENSORS_4711 mapReading_hugo 123 switch 0:paul 1:egon
für types ohne value-mapping (bei V_TEMP soll einfach nur der Wert unverändert durchgereicht werden) ist halt noch irgendwo der Wurm drin ;-)
ich habe immer noch seit dem Update Probleme mit dem Humidity sensor, da wird nix mehr erkannt.
CFGFN
DEF
127
IODev
im log steht aber alles
2014.11.07 21:24:18 5: MYSENSORS Read: Rx: fr=127 ci=255 c=003(C_INTERNAL ) st=011(I_SKETCH_NAME ) ack=0 'Humidity
2014.11.07 21:24:18 5: MYSENSORS Read: Rx: fr=127 ci=255 c=003(C_INTERNAL ) st=012(I_SKETCH_VERSION) ack=0 '1.0
2014.11.07 21:24:18 5: MYSENSORS Read: Rx: fr=127 ci=000 c=000(C_PRESENTATION) st=007(S_HUM ) ack=0 '1.4
2014.11.07 21:24:18 5: MYSENSORS Read: Rx: fr=127 ci=001 c=000(C_PRESENTATION) st=006(S_TEMP ) ack=0 '1.4
2014.11.07 21:24:19 5: MYSENSORS/RAW: /127;1;1;0;0;22.0
127;0;1;0;1;48.0
2014.11.07 21:24:19 5: MYSENSORS Read: Rx: fr=127 ci=001 c=001(C_SET ) st=000(V_TEMP ) ack=0 '22.0
2014.11.07 21:24:19 5: MYSENSORS Read: Rx: fr=127 ci=000 c=001(C_SET ) st=001(V_HUM ) ack=0 '48.0
2014.11.07 21:24:22 5: MYSENSORS outstanding ack, re-send: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=005(I_INCLUSION_MODE) ack=1 '1
2014.11.07 21:24:22 5: SW: 303b303b333b313b353b310a
2014.11.07 21:24:22 5: MYSENSORS/RAW: /0;0;3;0;5;1
2014.11.07 21:24:22 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=005(I_INCLUSION_MODE) ack=0 '1
2014.11.07 21:24:38 5: MYSENSORS outstanding ack, re-send: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=005(I_INCLUSION_MODE) ack=1 '1
2014.11.07 21:24:38 5: SW: 303b303b333b313b353b310a
2014.11.07 21:24:38 5: MYSENSORS/RAW: /0;0;3;0;5;1
2014.11.07 21:24:38 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=005(I_INCLUSION_MODE) ack=0 '1
2014.11.07 21:24:55 5: MYSENSORS outstanding ack, re-send: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=005(I_INCLUSION_MODE) ack=1 '1
2014.11.07 21:24:55 5: SW: 303b303b333b313b353b310a
2014.11.07 21:24:55 5: MYSENSORS/RAW: /0;0;3;0;5;1
gateway
I_SKETCH_NAME
Humidity
I_SKETCH_VERSION
1.0
NAME
MYSENSOR_127
NR
1480
STATE
???
TYPE
MYSENSORS_DEVICE
ack
0
protocol
1.4
radioId
127
repeater
0
Robin
so, hab mir grade einen TemperaturSensor zusammengesteckt und den Bug gefixed. Trat tatsächlich nur bei Sensortypen ohne explizites Werte-mapping auf. (http://sourceforge.net/p/fhem/code/6911/)
Danke supi, wann checkst du es über die fhep-update funktion ein? Hatte gerade mal geschaut, es war aber noch nicht aufgeführt.
List of new / modified files since last update:
UPD FHEM/37_harmony.pm
UPD FHEM/59_PROPLANTA.pm
UPD FHEM/59_Twilight.pm
UPD FHEM/98_RandomTimer.pm
UPD FHEM/98_WOL.pm
UPD docs/commandref.html
UPD docs/commandref_DE.html
Grusß Jens
Zitat von: fh555 am 07 November 2014, 23:28:41
wann checkst du es über die fhep-update funktion ein?
gar nicht, aus dem SVN kommt es mit etwas Verzögerung von selber im update an.
Supi, ist jetzt per update verfügbar, eingespielt und ging auf Anhieb 8)
Ich habe jetzt noch einen Bodenfeuchtesensor mit eingeklingt und funktioniert auch auf Anhieb.
Mal noch eine andere Frage ::)
Ist es möglich, daß das autocreate bei den MySensors Gateway die gefundenen Devices in eine andere Datei, als die fhem.cfg schreibt?
Ich habe der Übersichtlichkeit halber, meine Konfigurationsdateien ausgelagert und binde sie mit "include xxx" in der fhem.cfg ein.
include /opt/fhem/FHEM/fhem_interface.cfg
include /opt/fhem/FHEM/fhem_mysensors.cfg
include /opt/fhem/FHEM/fhem_lacrosse.cfg
include /opt/fhem/FHEM/fhem_it.cfg
und in der "fhem_mysensors.cfg" steht dann alles, was mit den MySensor-Devices zu tun hat.
define MYSENSOR_10 MYSENSORS_DEVICE 10
attr MYSENSOR_10 IODev MYS_GW
attr MYSENSOR_10 alias My_Switch
attr MYSENSOR_10 mapReading_tripped3 3 tripped 0:on 1:off
attr MYSENSOR_10 mode node
attr MYSENSOR_10 room MySensors
attr MYSENSOR_10 stateFormat tripped3
attr MYSENSOR_10 version 1.4
define MYSENSOR_30 MYSENSORS_DEVICE 30
attr MYSENSOR_30 IODev MYS_GW
attr MYSENSOR_30 alias My_Relais
attr MYSENSOR_30 mapReading_switch 1 switch
attr MYSENSOR_30 mode repeater
attr MYSENSOR_30 room MySensors
attr MYSENSOR_30 setReading_switch on,off
attr MYSENSOR_30 stateFormat switch
attr MYSENSOR_30 version 1.4b1 (18848a2)
usw
und in der "fhem_interfaces.cfg" steht zum Bsp.
###################################
## MySensors Gateway usb/seriell ##
###################################
define MYS_GW MYSENSORS /dev/ttyUSB1@115200
attr MYS_GW autocreate 1
attr MYS_GW icon cul_usb
attr MYS_GW room Gateway
attr MYS_GW stateFormat connection
attr MYS_GW verbose 5
Das autocreate ist aber auch "Global"? in der fhem.cfg aktiviert
define autocreate autocreate
attr autocreate autosave 1
attr autocreate device_room %TYPE
attr autocreate filelog ./log/%NAME-%Y.log
attr autocreate weblink 1
attr autocreate weblink_room Plots
Wenn also das neue MySensors Device per autocreate gefunden wurde, steht es ja unter "unsorted" und nach
"save config" steht es in der fhem.cfg.
Ich hätte aber lieber, wenn das was MySensors findet in der "fhem_mysensors.cfg" steht. Geht das?
nein, das musst Du dann von Hand in eigene Dateien splitten.
das autocreate werde ich vorraussichtlich noch so ändern, dass es das globale 'autocreate' (inklusive room etc.) berücksichtigt.
- Norbert
mhh, naja so mache ich das ja bisher. Ich dachte es geht einfacher ;)
Mal noch eine Frage ;)
Kann es sein, dass man bei MySensors nicht mit "alias" arbeiten kann?
Bsp.: welches funktioniert
define schalter1machwas notify MYSENSOR_40 { if (ReadingsVal("MYSENSOR_40","tripped","") eq "on") { fhem "set MYSENSOR_30 switch on" } else { fhem "set MYSENSOR_30 switch off" }}
und so geht es nicht
define My_Pir_Aktivitaet notify My_Pir { if (ReadingsVal("My_Pir","tripped","") eq "on") { fhem "set My_Relais switch on" } else { fhem "set My_Relais switch off" }}
definiert sind beide Teile, wie folgt
define MYSENSOR_30 MYSENSORS_DEVICE 30
attr MYSENSOR_30 IODev MYS_GW
attr MYSENSOR_30 alias My_Relais
attr MYSENSOR_30 mapReading_switch 1 switch
attr MYSENSOR_30 mode repeater
attr MYSENSOR_30 room MySensors
attr MYSENSOR_30 setReading_switch on,off
attr MYSENSOR_30 stateFormat switch
attr MYSENSOR_30 version 1.4b1 (18848a2)
define MYSENSOR_40 MYSENSORS_DEVICE 40
attr MYSENSOR_40 IODev MYS_GW
attr MYSENSOR_40 alias My_Pir
attr MYSENSOR_40 mapReading_tripped 1 tripped
attr MYSENSOR_40 mode node
attr MYSENSOR_40 room MySensors
attr MYSENSOR_40 stateFormat tripped
attr MYSENSOR_40 version 1.4b1 (18848a2)
gebe ich in der Befehlszeile in FHEM
set My_Relais switch on
kommt die Fehlermeldung:
Please define My_Relais first
ZitatKann es sein, dass man bei MySensors nicht mit "alias" arbeiten kann?
Das geht ja generell in FHEM nicht. Alias sind rein für die Anzeige da. ;)
Hi hexenmeister,
danke, das wußte ich nicht.
Temperaturmodul klappt immer noch nicht. Es wird zwar angelegt, jedoch keine Daten.
CFGFN
DEF
100
IODev
gateway
I_SKETCH_NAME
Temperature Sensor
I_SKETCH_VERSION
1.0
NAME
MYSENSOR_100
NR
4771
STATE
???
TYPE
MYSENSORS_DEVICE
ack
0
protocol
1.4
radioId
100
repeater
0
logfile alles tacco
2014.11.08 23:54:51 5: MYSENSORS/RAW: /100;0;1;0;0;26.8
2014.11.08 23:54:51 5: MYSENSORS Read: Rx: fr=100 ci=000 c=001(C_SET ) st=000(V_TEMP ) ack=0 '26.8
2014.11.08 23:55:23 5: MYSENSORS/RAW: /100;0;1;0;0;26.5
2014.11.08 23:55:23 5: MYSENSORS Read: Rx: fr=100 ci=000 c=001(C_SET ) st=000(V_TEMP ) ack=0 '26.5
2014.11.08 23:55:57 5: MYSENSORS/RAW: /100;0;1;0;0;26.2
2014.11.08 23:55:57 5: MYSENSORS Read: Rx: fr=100 ci=000 c=001(C_SET ) st=000(V_TEMP ) ack=0 '26.2
2014.11.08 23:56:32 5: MYSENSORS/RAW: /100;0;1;0;0;26.1
2014.11.08 23:56:32 5: MYSENSORS Read: Rx: fr=100 ci=000 c=001(C_SET ) st=000(V_TEMP ) ack=0 '26.1
2014.11.08 23:56:51 1: PERL WARNING: Useless use of private variable in void context at (eval 40992) line 1.
2014.11.08 23:56:51 1: PERL WARNING: Useless use of a constant (actual) in void context at (eval 40992) line 1.
2014.11.08 23:57:04 5: MYSENSORS/RAW: /100;0;1;0;0;25.9
2014.11.08 23:57:04 5: MYSENSORS Read: Rx: fr=100 ci=000 c=001(C_SET ) st=000(V_TEMP ) ack=0 '25.9
2014.11.08 23:57:38 5: MYSENSORS/RAW: /100;0;1;0;0;25.7
2014.11.08 23:57:38 5: MYSENSORS Read: Rx: fr=100 ci=000 c=001(C_SET ) st=000(V_TEMP ) ack=0 '25.7
2014.11.08 23:58:12 5: MYSENSORS/RAW: /100;0;1;0;0;25.6
2014.11.08 23:58:12 5: MYSENSORS Read: Rx: fr=100 ci=000 c=001(C_SET ) st=000(V_TEMP ) ack=0 '25.6
EDIT: Jetzt klappts.. inclusion-mode auf 1 und dann den Temperatur-Arduino resetten. Meiner Meinung nach ist die Inclusion-Zeit zu gering, weil der Temperatursensor nicht ständig sendet.
Hi,
I have an arduino pro mini with 3 temperature sensors connected to it. It's working fine and I can see the temperatures reaching both the serial gateway and Fhem. Problem is that Fhem only reads the sensor with the highest child ID for some reason.
I receive the following messages in the log:
2014.11.09 00:30:00 4: MYSENSORS_DEVICE Temp.VP: ignoring C_SET-message no reading-mapping for childId 0, type temperature
2014.11.09 00:30:00 4: MYSENSORS_DEVICE Temp.VP: ignoring C_SET-message no reading-mapping for childID 1, type temperature
The value from sensor with child ID 2 is logged and showed in the gui. If I remove map reading in config file for ChildID 2, values from ChildID 1 is logged instead. It's always only the sensor with the highest ChildID. I want to log values from all 3 ChildID's.
So am I missing something here or is this an unexpected behavior? :-\
My fhem.cfg file for this device looks like this: (created by the autoconfig)
define Temp.VP MYSENSORS_DEVICE 101
attr Temp.VP IODev gateway
attr Temp.VP mapReading_temperature 0 temperature
attr Temp.VP mapReading_temperature1 1 temperature
attr Temp.VP mapReading_temperature2 2 temperature
attr Temp.VP mode node
attr Temp.VP room L1
attr Temp.VP stateFormat temperature2
attr Temp.VP version 1.4
Thanks in advance!
Nach heutigem Update macht Fhem sowas
root@raspbmc:/opt/fhem# perl fhem.pl fhem.cfg
root@raspbmc:/opt/fhem# Use of uninitialized value in anonymous hash ({}) at ./FHEM/10_MYSENSORS_DEVICE.pm line 172, <$fh> line 2436.
Use of uninitialized value in anonymous hash ({}) at ./FHEM/10_MYSENSORS_DEVICE.pm line 172, <$fh> line 2436.
Use of uninitialized value in anonymous hash ({}) at ./FHEM/10_MYSENSORS_DEVICE.pm line 172, <$fh> line 2436.
Use of uninitialized value in anonymous hash ({}) at ./FHEM/10_MYSENSORS_DEVICE.pm line 172, <$fh> line 2438.
Use of uninitialized value in anonymous hash ({}) at ./FHEM/10_MYSENSORS_DEVICE.pm line 172, <$fh> line 2438.
Use of uninitialized value in anonymous hash ({}) at ./FHEM/10_MYSENSORS_DEVICE.pm line 172, <$fh> line 2438.
Broadcast message from root@raspbmc
(/dev/console) at 9:17 ...
The system is going down for reboot NOW!
Zitat von: fh168 am 09 November 2014, 09:19:54
Nach heutigem Update macht Fhem sowas
Use of uninitialized value in anonymous hash ({}) at ./FHEM/10_MYSENSORS_DEVICE.pm line 172, <$fh> line 2436.
Du musst die Dateien in FHEM/lib/Device/MySensors manuell (aus dem SVN) updaten, die kommen beim fhem-update (noch) nicht mit, das Direktory muss Rudolf König noch in den update-prozess mit aufnehmen.
Alternativ hier aus meinem git-repo:
Constants.pm (https://github.com/ntruchsess/fhem-mirror/raw/master/fhem/FHEM/lib/Device/MySensors/Constants.pm)
Message.pm (https://github.com/ntruchsess/fhem-mirror/raw/master/fhem/FHEM/lib/Device/MySensors/Message.pm)
Gruß,
Norbert
edit: habe Device/MySensors gerade in die contrib/fhemupdate.pl aufgenommen, ich hoffe damit kommen die Dateien in Zukunft beim update mit.
Der Fehler ist weg,
jedoch der hum sensor zeigt kein feuchtigkeitsreading an
EF
127
IODev
gateway
NAME
MYSENSOR_127
NR
1445
STATE
???
TYPE
MYSENSORS_DEVICE
ack
0
protocol
1.4
radioId
127
repeater
0
Readings
temperature1
23.0
2014-11-09 12:15:06
2014.11.09 12:15:09 5: MYSENSORS Read: Rx: fr=100 ci=255 c=003(C_INTERNAL ) st=011(I_SKETCH_NAME ) ack=0 'Temperature Sensor'
2014.11.09 12:15:09 5: MYSENSORS Read: Rx: fr=100 ci=255 c=003(C_INTERNAL ) st=012(I_SKETCH_VERSION) ack=0 '1.0'
2014.11.09 12:15:09 5: MYSENSORS Read: Rx: fr=100 ci=000 c=000(C_PRESENTATION) st=006(S_TEMP ) ack=0 '1.4'
2014.11.09 12:15:09 5: MYSENSORS/RAW: /100;0;1;0;0;23.3
2014.11.09 12:15:09 5: MYSENSORS Read: Rx: fr=100 ci=000 c=001(C_SET ) st=000(V_TEMP ) ack=0 '23.3'
2014.11.09 12:15:15 5: MYSENSORS/RAW: /0;0;3;0;5;0
2014.11.09 12:15:15 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=005(I_INCLUSION_MODE) ack=0 '0'
2014.11.09 12:15:22 1: PERL WARNING: Useless use of private variable in void context at (eval 163) line 1.
2014.11.09 12:15:22 1: PERL WARNING: Useless use of a constant (actual) in void context at (eval 163) line 1.
2014.11.09 12:15:23 1: PERL WARNING: Useless use of private variable in void context at (eval 164) line 1.
2014.11.09 12:15:23 1: PERL WARNING: Useless use of a constant (actual) in void context at (eval 164) line 1.
2014.11.09 12:17:31 1: PERL WARNING: Useless use of private variable in void context at (eval 189) line 1.
2014.11.09 12:17:31 1: PERL WARNING: Useless use of a constant (actual) in void context at (eval 189) line 1.
2014.11.09 12:19:37 5: MYSENSORS/RAW: /127;0;1;0;1;42.0
2014.11.09 12:19:37 5: MYSENSORS Read: Rx: fr=127 ci=000 c=001(C_SET ) st=001(V_HUM ) ack=0 '42.0'
2014.11.09 12:20:07 1: gateway is against deletion (connection: disconnected), continuing with rereadcfg anyway
2014.11.09 12:20:08 1: Including fhem.cfg
2014.11.09 12:20:15 1: Including ./log/fhem.save
2014.11.09 12:20:18 3: Opening gateway device 192.168.178.234:5003
2014.11.09 12:20:18 3: gateway device opened
2014.11.09 12:20:18 5: MYSENSORS send: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=002(I_VERSION ) ack=0 ''
2014.11.09 12:20:18 5: SW: 303b303b333b303b323b0a
2014.11.09 12:20:27 5: MYSENSORS/RAW: /0;0;3;0;14;Gateway startup complete.
0;0;3;0;2;1.4
2014.11.09 12:20:27 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=014(I_STARTUP_COMPLETE) ack=0 'Gateway startup complete.'
2014.11.09 12:20:28 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=002(I_VERSION ) ack=0 '1.4'
2014.11.09 12:20:31 1: PERL WARNING: Useless use of private variable in void context at (eval 248) line 1.
2014.11.09 12:20:31 1: PERL WARNING: Useless use of a constant (actual) in void context at (eval 248) line 1.
2014.11.09 12:23:15 1: PERL WARNING: Useless use of private variable in void context at (eval 301) line 1.
2014.11.09 12:23:15 1: PERL WARNING: Useless use of a constant (actual) in void context at (eval 301) line 1.
Zitat von: Aloha am 09 November 2014, 02:16:26
2014.11.09 00:30:00 4: MYSENSORS_DEVICE Temp.VP: ignoring C_SET-message no reading-mapping for childId 0, type temperature
2014.11.09 00:30:00 4: MYSENSORS_DEVICE Temp.VP: ignoring C_SET-message no reading-mapping for childID 1, type temperature
fixed in rev. 6923 (http://sourceforge.net/p/fhem/code/6923/). Sometimes a pair of parentheses makes a difference ;-)
- Norbert
Zitat von: ntruchsess am 09 November 2014, 12:46:15
fixed in rev. 6923 (http://sourceforge.net/p/fhem/code/6923/). Sometimes a pair of parentheses makes a difference ;-)
- Norbert
That was quick! I just tested it and it works very well now. :)
Thanks!
Zitat von: fh168 am 09 November 2014, 12:24:01
jedoch der hum sensor zeigt kein feuchtigkeitsreading an
NAME MYSENSOR_127
TYPE MYSENSORS_DEVICE
radioId
127Readings temperature
1 23.0
2014.11.09 12:19:37 5: MYSENSORS Read: Rx: fr=
127 ci=000 c=00
1(C_SET ) st=001(V_HUM ) ack=0 '42.0'
Lass die Devices noch mal sauber neu anlegen, für RadioId 127, ChildId 1 ist ja temperature und nicht humidity eingetragen. Oder korrigiere das manuell mit 'attr MYSENSOR_127 1 humidity'
Wenn das 'attr MYSENSOR_127 1 humidity' vom autocreate angelegt wurde, dann solltest Du auf SVN-Rev. 6923 updaten.
Übrigens: wenn Du einen Sensor neu flashst, dann bleibt die diesem Arduino schon mal zugewiesene RadioId im Eeprom erhalten.
Gruß,
Norbert
hat nichts gebracht, hab den hum noch mal von der config entfernt, ihn nochmal neu geflasht
und auch das snippet funktionierte nicht.
MYSENSOR_127: unknown attribute 1. Type 'attr MYSENSOR_127 ?' for a detailed list.
Since my temperature sensors are working fine now I continued with testing a power meter pulse sensor. It was not recognised automatically by the autoconfig so I tried to configure it manually.
Fhem gives the sensor an ID but nothing more. Before defining it manually I can see the following in the logs.
2014.11.09 12:25:32 3: MYSENSORS: ignoring req-msg from unknown radioId 102, childId 1 for V_VAR1
After defining the sensor and Fhem receives the first data from it, Fhem prints out the following error message to the console and then crashes. I have to turn off the sensor if I want to be able to start it again.
Undefined subroutine &MYSENSORS::DEVICE::ReadingsVal called at ./FHEM/10_MYSENSORS_DEVICE.pm line 428.
So, my question is if this type of sensor is supported yet?
Undefined subroutine &MYSENSORS::DEVICE::ReadingsVal called at ./FHEM/10_MYSENSORS_DEVICE.pm line 428. -> fixed in rev. 6929 (http://sourceforge.net/p/fhem/code/6929/).
Zitat von: Aloha am 09 November 2014, 15:18:15
Since my temperature sensors are working fine now I continued with testing a power meter pulse sensor. It was not recognised automatically by the autoconfig[...]
could you update to latest svn, remove all attributes of MYSENSOR_102 leaving/setting 'attr MYSENSOR_102 verbose 5' and also attr verbose 5 on the MYSENSOR-gateway device and then redo the autocreate and post the output (everything that shows up after turning on the sensor?
EDIT: added fix for processing of request-msg: rev. 6931 (http://sourceforge.net/p/fhem/code/6929/). This is required for S_POWER-sensor
Did you change anything else? This time the autoconfig worked and the sensor was added. :)
There was a slight problem though. If I connect the sensor before enabling autoconfig Fherm crash with the following error message:
no reading-mapping for childId 1, type value1 at ./FHEM/10_MYSENSORS_DEVICE.pm line 530.
And the last thing the logs show:
2014.11.09 19:07:00 5: MYSENSORS gateway gateway: read: 102-102-0 s=1,c=0,t=13,pt=0,l=3:1.4
2014.11.09 19:07:00 5: MYSENSORS Read: Rx: fr=102 ci=001 c=000(C_PRESENTATION) st=013(S_POWER ) ack=0 '1.4'
2014.11.09 19:07:00 4: MYSENSORS_DEVICE node: errors on C_PRESENTATION-message for childId 1, subType S_POWER no mapReading for 1, power, no mapReading for 1, energy, no mapReading for 1, value1, no setReading for 1, value1
2014.11.09 19:07:00 5: MYSENSORS/RAW: 0;0;3;0;9;read: 102-1/02-0 s=1,c=2,t=24,pt=0,l=3:1.4
102;1;2;0;24;1.4
2014.11.09 19:07:00 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'read: 102-102-0 s=1,c=2,t=24,pt=0,l=3:1.4'
2014.11.09 19:07:00 5: MYSENSORS gateway gateway: read: 102-102-0 s=1,c=2,t=24,pt=0,l=3:1.4
2014.11.09 19:07:00 5: MYSENSORS Read: Rx: fr=102 ci=001 c=002(C_REQ ) st=024(V_VAR1 ) ack=0 '1.4'
/ Thomas
Thank's for reporting. I didn't build a sensor that uses C_REQ-message yet, so this is valueable for me.
Zitat von: Aloha am 09 November 2014, 19:22:31
Did you change anything else? This time the autoconfig worked and the sensor was added. :)
no nothing else changed. Seems the gateway didn't receive the presentation-messages while inclusion-mode was active.
Zitat von: Aloha am 09 November 2014, 19:22:31
no reading-mapping for childId 1, type value1 at ./FHEM/10_MYSENSORS_DEVICE.pm line 530.
-> fixed in rev. 6934 (http://sourceforge.net/p/fhem/code/6934/). (Now it's logged, not crashing).
Hallo Norbert,
hast du mal den 433MHzSensor aus der MySensor Library zusammengesteckt?
Klasse Sache, ich bekomme von meinem Nachbarn die Temperatur von dem 433 MHz Thermometer angezeigt.
Verdammt kalt geworden :-).
Wenn man eine Steckdosen-Baumarkt-Fernbedienung besitzt, kann man da auch die Codes herausbekommen.
Wäre schön wenn man das in Fhem auch sofort einbauen könnte :-)
Temperature: 10.4
Temperature: 10.4
Temperature: 10.4
Temperature: 10.4
Code: 6068, period: 324us.
Temperature: 10.4
Temperature: 10.4
Temperature: 10.4
Temperature: 10.4
Man sollte bei den 433 MHz - Receivern nicht die billigen kaufen, die funktionieren nur einige Meter. Ich habe das in meinem Blog damals nochmal erwähnt http://blog.moneybag.de/fhem-preiswerter-433-mhz-funkbewegungsmelder-pir/
LG
/robin
das ist ja nett, habe ich aber noch nicht mit gespielt ;-)
Hast Du Vorschläge, was man da wie 'integrieren' würde? (Also was soll fhem machen, wenn eine bestimmte Message reinkommt?)
Hallo Norbert,
logo habe ich das:
Vielleicht könnte man den Sketch erweitern das man auch noch 433 MHz senden kann..
Vorschläge:
Man könnte wie oben beschrieben die 433 MHz Thermometer empfangen, interessant, das es bei mir sofort geklappt hat.
Man könnte mit einer billig Baumarkt-Fernbedienung bspw. nicht nur Steckdosen schalten sondern auch eine Philips oder oder komplette Scenes an und ausschalten.
Man könnte die Daten von einem 433 MHz-Bewegungsmelder abfangen:
http://blog.moneybag.de/fhem-preiswerter-433-mhz-funkbewegungsmelder-pir/
Man könnte die DAetn von einem 433 MHz-Tür-Fensterkontakt abfangen:
http://blog.moneybag.de/tuer-fenster-kontakt-sensor-auf-433-mhz-basis/
Ich habe damals mal ein Video darüber gemacht, viele positive Reaktionen bekommen. Ich komme aber derzeitig noch nicht dazu, noch eins zu machen:
https://www.youtube.com/watch?v=sHT_ubQH4nk
Ich habe noch ein paar von den 433-MHz Emfänger, haben eine gute Reichweite.
Die einzelnen Module habe ich bei mir im Einsatz, auch Empfang über den Arduino. Im Grunde müsste man den Source-Code nur mit dem Mysensors-Code verbinden. ich bin aber nicht so da im Thema.
Das Senden geht von derzeitig noch über den Raspberry Pi ist aber auch kein Hexenwerk.
Wie gesagt im ersten Schritt könnte man die empfangenen Daten (Temperatur, Baumarkt-FB) in Fhem automatisch als Reading (?) anlegen lassen. Und die kann man ja wieder mit Fhem auslesen.
LG
/robin
jetzt habe ich mal einen Blick in den RF433MhzSensor.ino-sketch geworfen, der bei den MySensors-beispielen dabei ist.Der kommuniziert ja gar nicht über die MySensors-library, wieso haben die den überhaupt mit zu den Beispielen gepackt? Ich sehe keine sinnvolle Möglichkeit das in die MYSENSORS-module zu integrieren.
Zur Kommunikation mit 433MHz Geräten gibt es ja schon einige andere FHEM-Module mit anderer Basis.
schade, dann hätte ich wieder einen USB-Platz frei bekommen. Derzeitig nehme ich zum Empfang von 433 MHz Signalen einen Arduino Nano mit 433 Mhz-Empfänger.
Hallo,
ich habe mal wieder eine Frage (welche nicht expliziert mit MySensors zu tun hat) :
Man kann ja an ein Modul mehrere Sensoren anschließen aber wie bekommt man diese verschiedenen Sensoren für das entsprechende Modul grafisch in der Weboberfläche angezeigt?
Bsp.:
Modul_100
|
Switch_1 on
Switch_2 off
Temperature 25.0
Im Anhang mal die Konfiguration von einen Dual-Switch,
also ggf. 2 von diesen Lampen-Symbolen oder statt den Lampen-Symbol zwei Schalter oder on/off.
die Stichworte 'readingsProxy (http://fhem.de/commandref.html#readingsProxy)' bzw. 'readingsGroup (http://fhem.de/commandref.html#readingsGroup)' sollten Dir hier weierhelfen.
Hallo zusammmen
Ich scheitere bereits ganz am Anfang und benötige einen Schubser von euch ;)
Auf einen Arduino Uno mit Wiznet5100 habe ich mittels Arduino-Tool 1.58 den Example Sketch MySensors/Ethernet/ErthernetGateway geladen. Danach die Macadresse und die IP des Arduino angepasst:
#include <SPI.h>
#include <MySensor.h>
#include <MyGateway.h>
#include <stdarg.h>
// Use this fo WizNET module and Arduino Ethernet Shield
#include <Ethernet.h>
#define INCLUSION_MODE_TIME 1 // Number of minutes inclusion mode is enabled
#define INCLUSION_MODE_PIN 3 // Digital pin used for inclusion mode button
#define RADIO_CE_PIN 5 // radio chip enable
#define RADIO_SPI_SS_PIN 6 // radio SPI serial select
#define RADIO_ERROR_LED_PIN 7 // Error led pin
#define RADIO_RX_LED_PIN 8 // Receive led pin
#define RADIO_TX_LED_PIN 9 // the PCB, on board LED
#define IP_PORT 5003 // The port you want to open
IPAddress myIp (192, 168, 2, 104); // Configure your static ip-address here COMPILE ERROR HERE? Use Arduino IDE 1.5.7 or later!
// The MAC address can be anything you want but should be unique on your network.
// Newer boards have a MAC address printed on the underside of the PCB, which you can (optionally) use.
// Note that most of the Ardunio examples use "DEAD BEEF FEED" for the MAC address.
byte mac[] = { 0xDF, 0xDA, 0x51, 0x7C, 0x29, 0x85 }; // DEAD BEEF FEED
// a R/W server on the port
EthernetServer server = EthernetServer(IP_PORT);
// No blink or button functionality. Use the vanilla constructor.
MyGateway gw(RADIO_CE_PIN, RADIO_SPI_SS_PIN, INCLUSION_MODE_TIME);
// Uncomment this constructor if you have leds and include button attached to your gateway
//MyGateway gw(RADIO_CE_PIN, RADIO_SPI_SS_PIN, INCLUSION_MODE_TIME, INCLUSION_MODE_PIN, RADIO_RX_LED_PIN, RADIO_TX_LED_PIN, RADIO_ERROR_LED_PIN);
char inputString[MAX_RECEIVE_LENGTH] = ""; // A string to hold incoming commands from serial/ethernet interface
int inputPos = 0;
void setup()
{
// Initialize gateway at maximum PA level, channel 70 and callback for write operations
gw.begin(RF24_PA_LEVEL_GW, RF24_CHANNEL, RF24_DATARATE, writeEthernet);
Ethernet.begin(mac, myIp);
// give the Ethernet interface a second to initialize
delay(1000);
// start listening for clients
server.begin();
}
// This will be called when data should be written to ethernet
void writeEthernet(char *writeBuffer) {
server.write(writeBuffer);
}
void loop()
{
// if an incoming client connects, there will be
// bytes available to read via the client object
EthernetClient client = server.available();
if (client) {
// if got 1 or more bytes
if (client.available()) {
// read the bytes incoming from the client
char inChar = client.read();
if (inputPos<MAX_RECEIVE_LENGTH-1) {
// if newline then command is complete
if (inChar == '\n') {
// a command was issued by the client
// we will now try to send it to the actuator
inputString[inputPos] = 0;
// echo the string to the serial port
Serial.print(inputString);
gw.parseAndSend(inputString);
// clear the string:
inputPos = 0;
} else {
// add it to the inputString:
inputString[inputPos] = inChar;
inputPos++;
}
} else {
// Incoming message too long. Throw away
inputPos = 0;
}
}
}
gw.processRadioMessage();
}
Das Compilieren wie auch der Upload funktioniert problemlos und bekomme auch keine Fehlermeldungen. Wenn ich aber danach einen Ping absetze auf die IP des Arduino (192.168.2.104) bekomme ich keine Antwort.
Um sicherzustellen, dass die Hardware funktioniert, habe ich den Ethernet WebServer aus der Standard Liberary installiert (gleiche IP und gleiche MAC Adresse), danach hat der Arduino schön brav auf die Pings geantwortet.
Kann mir jemand einen Tipp geben?
Danke und Gruss Dani
schließ mal den Serial-monitor (115200 baud) an, und schau, ob der Sketch überhaupt sauber initialisiert. Wenn das nRF24L01-modul nicht korrekt verbunden ist, kommt da 'check wires', ansonsten sowas wir 'startup ok'
Hallo Norbert
Danke für den Tip! Im Serial Monitor kommt:
0;0;3;0;9;check wires
Ich habe noch kein nRF24L01 angeschlossen (Nur Ethernet und USB-Power). Könnte das der Grund sein, dass ich ihn nicht pingen kann?
Gruss Dani
ja
Hallo Norbert
Ich habe nun das nRF24L01 wie folgt angeschlossen:
GND GND
3.3V VCC
A2 MISO
A1 MOSI
A0 SCK
6 CSN
5 CE
Leider lässt sich der Arduino nach wie vor nicht pingen. Ich habe mal noch den MQTT-Gateway Sketch in der MySensors Library versucht, der funktioniert auf anhieb.
Hast du noch einen Tip wo ich suchen könnte?
Danke und Gruss Dani
Hallo,
wie kann man eigentlich einen Wert (ausser on,off) zum Sensor schicken?
Ich habe einen Aussensensor für Temp. und Feuchtigkeit und einen Innensensor auch mit Temperatur. Der Innensensor bekommt ein kl. Display.
Nun möchte ich auf den Display die Innentemp. und zusätzlich die Aussentemperatur/Feuchtigkeit anzeigen lassen.
Vielen Dank schon im vorraus.
BobbyD
Hallo zusammen
Ich bringe den Gateway einfach nicht zum rennen. Welchen Sketch verwendet ihr?
Für jeden Tipp bin ich dankbar.
Danke & Gruss Dani
Hallo Dani,
ich hatte Anfangs auch ähnliche Probleme wie Du, MQQT-Sketch funktioniert, der "normale" nicht.
Hier im Thread ein paar Seiten vorher gibt's einen, mit dem hat es dann funktioniert.
Es lief allerdings zuerst nicht zuverlässig (nach kurzer Zeit keine Funkverbindung), habe dann auf Soft-SPI umgestellt, jetzt läuft er seit 2 Tagen
hier meine überarbeitete Version, die keine Probleme mit mehrfachem Reconnect haben sollte: EthernetGateway.ino (https://github.com/ntruchsess/MySensors/raw/ethernet_gw/libraries/MySensors/examples/EthernetGateway/EthernetGateway.ino)
Zitat von: BobbyD am 15 November 2014, 12:10:13
wie kann man eigentlich einen Wert (ausser on,off) zum Sensor schicken?
Wenn man keinen der Standard-sketches verwendet, dann kennt das Modul keine sinnvollen Defaults. Kann man aber über die Attribute komplett selber konfigurieren. Um Werte an Aktoren zu schicken verwendet man die Attribute 'setCommands' und 'setReading' (http://fhem.de/commandref.html#MYSENSORS_DEVICE).
@ntruchsess
Zitat
die Stichworte 'readingsProxy' bzw. 'readingsGroup' sollten Dir hier weierhelfen.
define MYSENSOR_100 MYSENSORS_DEVICE 100
attr MYSENSOR_100 IODev MYS_GW
attr MYSENSOR_100 alias 100_My_Switch_2x
attr MYSENSOR_100 comment 3V CR2032 am 16.11.2014 / 20:00 Uhr
attr MYSENSOR_100 mapReading_tripped3 3 tripped 0:on 1:off
attr MYSENSOR_100 mapReading_tripped4 4 tripped 0:on 1:off
attr MYSENSOR_100 mode node
attr MYSENSOR_100 room MySensors
attr MYSENSOR_100 stateFormat tripped3 tripped4
attr MYSENSOR_100 version 1.4.1
meinst du so?
define MYSENSOR_100_GRP readingsGroup MYSENSOR_100:tripped3 MYSENSOR_100:tripped4
attr MYSENSOR_100_GRP room MySensors
Gruß Jens
P.S.: Ergebnis als Bild
@Jens, ich bin gespannt, wie lange die Knopfzelle hält :-)
@Robin,
ich auch :-)
Meine erste "Testzelle" war leider gebraucht, jetzt ist eine frische drinn. Ich muss nur noch den "BOD Level" anders setzen.
So wie es ausieht schaltet der Pro Mini 3V3@8Mhz bei 2V7 shon ab! Das ist natürlich nicht im Sinne des Erfinders ;)
Ich muß den erst einmal auf 1.8V runtersetzen oder ggf. gleich abstellen.
Hast du den Sketch mal probiert? soll jetzt der "Stromspar-Sketch" für die Schalter sein. Wäre ja cool, wenn der Verbrauch wirklich sehr niedrig ist. Somit könntest du z.Bsp. ein Doppelfenster getrennt mit nur einen Sender überwachen und das wäre natürlich auch preislich der Hammer im Gegensatz zu den "Fertigsensoren".
Gruß Jens
Mich würde mal interessieren wie ihr die Sensoren mi Batterie betreibt ?
Gibt ja verschiedene Ansätze, 1-2 Zellen und Step-Up Wandler, nach langem lesen denke ich eher 4 Zellen und den internen Spannungsregler vom Arduino Mini Pro nehmen ?
Bin gespannt was aus mysensors und FHEM wird, denke hier steckt viel Potential drin, endlich eine Alternative zum undurchsichtigen Homematic
Hallo Klaus,
es kommt drauf an welche Sensoren dran angeschlossen sind.
Ich experimentier gerade mit Tür-Fensterkontakt-Sensoren, und da nehme ich den Pro-Mini mit 3.3 Volt, weil er ja stromsparend sein soll und sonst nicht belastet wird.
Jens prüft ja gerade wie lang das Teil durchhält.
Für die Temperaturmessung nehme ich einen 3.3 V Pro Mini und einen DS18B20.
Eine andere Sache ist z.B. das Schalten von Relais, da würde ich einen Nano nehmen, wegen den notwendigen 5V Versorgungsspannung bei Relais und 3.3 V für den nRF.
Wichtig ist auch das das ganze stabil läuft. Sieht bei mir aber mittlerweile sehr gut aus. Ich teste schon 2 Wochen im Dauerbetrieb Gateway LAN, keine Abbrüche.. (wenn ich nicht dauernd basteln würde..)
robin
so mal ein kurzes Resümee zu meine "Dual-Switch" auf einen Arduino Pro Mini 3V3@8 Mhz ;)
Testhardware:
1x unveränderter MiniPro 3V3
1x CR2032 (3V, ca. 200mA)
1x NRF24L01+
2x Schalter
Software:
BinarySwitchSleepSensor
Ich wollte zwecks Planung der Batteriebetriebenen Sensoren mal sehen, wie es am sinnvollsten ist, diese Teile zu betreiben.
Verwendung von Batterien/Akkus (erst einmal ohne zusätzliche Step-Up Wandler) und dementsprechend auch die Größe des Gehäuses.
Naja eins ist schon einmal klar, mit einer Knopfzelle wird das leider nichts :(
Der MiniPro 3V3 zieht in "Ruhe" in diesen Testaufbau ca. 1,5 mA (Hardware unverändert), rechnerisch würde das theoretisch über 100 Stunden sein also, sagen wir mal ca. 4-5 Tage.
Naja lange ist das nicht, aber ..... der ProMini 3V3 ist per Fuses "Bodlevel" auf 2,7V eingestellt, also für diese Zwecke total unpraktisch, da der ProMini und der NRF24L01+ auch bis 2V noch funktionieren! In meinen Fall konnte ich also nur 0,3V verbrauchen,
bis die Abschaltung vom Controller kam >:(
Also die Fuses auf 1,8V abgeändert, aber bei mir gibt er trotzdem bei 2,7V den Geist auf.
Das heisst gerade einmal eine Laufzeit von ca. 24 Stunden!
Ich überlege mal, was mir noch so einfällt, was man machen könnte. Als nächstes wird wohl die Fehlersuche sein, warum er immer noch bei 2,7V abschaltet, dann ggf. die Hardwaremodifikation am ProMini.
Vernünftige und auch preiswerte Step-Up Wandler bei deutschen Lieferanten, welche ggf. Step-Up/-Down können, habe ich bisher leider nicht gefunden.
Ich bleibe auf jeden Fall am Ball ;D
Gruß Jens
Einen fertigen, guten und noch sparsamen StepUpDown wirst Du vermutlich nicht finden. Aber muss das unbedingt ein StepUpDown sein?
Allerdings einen fertigen und sparsamen StepUp habe ich auch nicht finden können. Ein guter Baustein ist max1724 daraus kann man einen sehr sparsamen selbst anfertigen. Ist jedoch nicht ganz trivial.
Hast Du LED heruntergelötet? Ansonsten ist der Verbrauch wirklich sehr hoch. Ich habe mal gemessen (http://s6z.de/cms/index.php/arduino/nuetzliches/9-winterschlaf-fuer-arduino (http://s6z.de/cms/index.php/arduino/nuetzliches/9-winterschlaf-fuer-arduino)), zwar nicht mit MySensors-Lib, aber man bekommt Arduino schon sehr sparsam. Allerdings gibt es auch widerspenstige Exemplare.
@hexenmeister
Zitat
Testhardware:
1x unveränderter MiniPro 3V3
1x CR2032 (3V, ca. 200mA)
1x NRF24L01+
2x Schalter
wie schon geschrieben, der MiniPro ist noch unverändert. Ich habe die LED noch "aktiv" und auch den internen Spannungswandler noch nicht getrennt. Ich denke mal LED=1mA und der nichtgenutzte Spannaungsregler in Ruhe evtl. =200 - 300uA.
Würde ich beides abziehen, komme ich theoretisch auf ca. 0,25mA - 0,5mA.
Da ich nur 2x 3V3 MiniPro's habe, wollte ich nicht gleich mit den Lötkolben und den Messer ran.
Das größere Problem, welches ich noch habe ist der BODLEVEL von 2,7V!
Angeblich sind sie jetzt auf 1,8V gesetzt aber er spinnt (stellt seine Arbeit ein) wenn ich an die 2,7V ran komme.
Wenn vermeidbar wollte ich die Schaltung nur mit 2xAA Batterien betreiben, direkt an den 3V3 Input-Pin also ohne Step-Up/-Down.
Zitat von: fh555 am 20 November 2014, 22:35:01
@hexenmeister
wie schon geschrieben, der MiniPro ist noch unverändert. Ich habe die LED noch "aktiv" und auch den internen Spannungswandler noch nicht getrennt. Ich denke mal LED=1mA und der nichtgenutzte Spannaungsregler in Ruhe evtl. =200 - 300uA.
Würde ich beides abziehen, komme ich theoretisch auf ca. 0,25mA - 0,5mA.
Habe beim schnellen Überfliegen wohl nicht wahrgenommen. Aber die Werte könnten passen (eigentlich hätte ich noch kleiner erwartet).
ZitatDa ich nur 2x 3V3 MiniPro's habe, wollte ich nicht gleich mit den Lötkolben und den Messer ran.
Die Power LED ist je entbehrlich. Kannst ja auch immer wieder einlöten (einfacher als LED ist ihre Vorwiderstand auszulöten).
Zitat
Das größere Problem, welches ich noch habe ist der BODLEVEL von 2,7V!
Angeblich sind sie jetzt auf 1,8V gesetzt aber er spinnt (stellt seine Arbeit ein) wenn ich an die 2,7V ran komme.
Hm... Das hat bei mir funktioniert. Ich habe eine Anleitung gefunden, wie man ein neues Board in der ArduinoIDE anlegt, mit einem gewünschten Level für BOD. Dann muss man nur aus der IDE den Botloader aufspielen.
ZitatWenn vermeidbar wollte ich die Schaltung nur mit 2xAA Batterien betreiben, direkt an den 3V3 Input-Pin also ohne Step-Up/-Down.
Müsste gehen.
@hexenmeister
Ich habe das mit den BOD wie folgt gemacht:
in der "boards.txt" einen neuen Controller angelegt (Eintrag vom MiniPro (3.3V, 8 MHz) w/ ATmega328 kopiert und als neuen MiniPro-BOD angelegt)
dann die "pro.menu.cpu.8MHzatmega328bod18.bootloader.extended_fuses=0x05" von 0x05 (2,7V) auf 0x06 (1,8V) abgeändert,
dann Bootlader neu auf den MiniPro übertragen,
dann über avrdude "read extended_fuses" ausgelesen, ausgelesener Wert= 0x06
Also hat es funktioniert, aber er macht bei mir bei 2,7V dicht :'(
Habe ich etwas vergessen oder falsch gemacht?
Mein schönes neues Breadboard scheint eine Macke zu haben >:(
Jetzt nach Austausch des Breadboards und Entfernung des Vorwiderstandes der Power-LED komme ich auf folgende Werte.
Ich denke, ich starte das Experiment mit einer neuer CR2032 noch einmal, da die Stromaufnahme ja jetzt "Himmlische Werte" hat.
Soooo, nun die neuen Werte ;D
Arduino ProMini 3V3@8Mhz, BOD 1,8V
Bootup = 18mA
switch 1 = 7,27mA (senden)
switch 2 = max 1mA (senden)
Sleep = 0,056 - 0,058 mA
Sketch = Dual-Switch-Stromspar
LG Jens
P.S.: Es stellt sich natürlich die Frage, warum beim Betätigen des "Switch-1" die Stromaufnahme um das 7fache höher ist!?!
Hätte auch eine Idee: Einfach eine kleine Solarzelle an den Akku klemmen. z.B. bei Lichtschaltern lädt gleich der Akku mit auf, wenn das Licht an ist. :-)
Zitat von: fh555 am 21 November 2014, 00:36:17
Mein schönes neues Breadboard scheint eine Macke zu haben >:(
Kenne ich ;)
Zitat
Ich denke, ich starte das Experiment mit einer neuer CR2032 noch einmal, da die Stromaufnahme ja jetzt "Himmlische Werte" hat.
...
Sleep = 0,056 - 0,058 mA
"Himmlisch" sind sie nicht, aber schon sehr-sehr gut. Der theoretische Minimum ist zwar noch drunter, aber richtig lohnen tun sich weitere Maßnahmen nicht ;)
ZitatP.S.: Es stellt sich natürlich die Frage, warum beim Betätigen des "Switch-1" die Stromaufnahme um das 7fache höher ist!?!
In der Tat sonderbar...
Was hat eigentlich mit dem BOD zunächst nicht funktioniert? Sieht ja richtig aus...
Bei den Switch muss ich auch noch einmal die Kontaktleiste tauschen, nicht das dort auch eine Macke ist!
Zitat von: hexenmeister am 21 November 2014, 08:28:16
Was hat eigentlich mit dem BOD zunächst nicht funktioniert? Sieht ja richtig aus...
Er hat, wenn ich unter 2,7V kam nur sehr langsam reagiert bzw. gar nicht mehr wirklich. Gesendet hat er auch nicht mehr!
Aber das konnte auch am fehlerhaften Breadboard gelegen haben.
Schaun ma mal, was der neue Test so bringt :-)
Hello!
Here's some more feedback. The latest sensor I'm trying to add is a water sensor. However, fhem crashes immediately when I power it up. It doesn't matter if the gateway is in inclusion mode or not. I've tried to increase the logging but it doesn't show too much. Here's what I got.
Error message sent to console when it crashes:
/opt/fhem $ no reading-mapping for childId 5, type value1 at ./FHEM/10_MYSENSORS_DEVICE.pm line 530.
Log from water meter when I turn it on until it crashes:
2014.11.21 21:02:04 5: MYSENSORS/RAW: 0;0;3;0;9/;read: 103-103-0 s=255,c=0,t=17,pt=0,l=3:1.4
1
2014.11.21 21:02:04 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'read: 103-103-0 s=255,c=0,t=17,pt=0,l=3:1.4'
2014.11.21 21:02:04 5: MYSENSORS gateway gateway: read: 103-103-0 s=255,c=0,t=17,pt=0,l=3:1.4
2014.11.21 21:02:04 5: MYSENSORS/RAW: 1/03;255;0;0;17;1.4
0;0;3;0;9;read: 103-103-0 s=255,c=3,t=6,pt=1,l=1
2014.11.21 21:02:04 5: MYSENSORS Read: Rx: fr=103 ci=255 c=000(C_PRESENTATION) st=017(S_ARDUINO_NODE ) ack=0 '1.4'
2014.11.21 21:02:04 5: MYSENSORS/RAW: 0;0;3;0;9;read: 103-103-0 s=255,c=3,t=6,pt=1,l=1/:0
103;255;3;0;6;0
2014.11.21 21:02:04 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'read: 103-103-0 s=255,c=3,t=6,pt=1,l=1:0'
2014.11.21 21:02:04 5: MYSENSORS gateway gateway: read: 103-103-0 s=255,c=3,t=6,pt=1,l=1:0
2014.11.21 21:02:04 5: MYSENSORS Read: Rx: fr=103 ci=255 c=003(C_INTERNAL ) st=006(I_CONFIG ) ack=0 '0'
2014.11.21 21:02:04 5: MYSENSORS send: Rx: fr=103 ci=255 c=003(C_INTERNAL ) st=006(I_CONFIG ) ack=0 'M'
[...]
2014.11.21 21:02:06 5: MYSENSORS Read: Rx: fr=103 ci=255 c=003(C_INTERNAL ) st=011(I_SKETCH_NAME ) ack=0 'Water Meter'
2014.11.21 21:02:06 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'read: 103-103-0 s=255,c=3,t=12,pt=0,l=3:1.0'
2014.11.21 21:02:06 5: MYSENSORS gateway gateway: read: 103-103-0 s=255,c=3,t=12,pt=0,l=3:1.0
2014.11.21 21:02:06 5: MYSENSORS/RAW: 103;255;3;0;12/;1.0
0;0;3;0;9;read: 103-103-0 s=5,c=0,t=21,pt=0,l=3:1.4
103;5;0;0;21;1.4
0;0;3;0;9;re
2014.11.21 21:02:06 5: MYSENSORS Read: Rx: fr=103 ci=255 c=003(C_INTERNAL ) st=012(I_SKETCH_VERSION) ack=0 '1.0'
2014.11.21 21:02:06 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'read: 103-103-0 s=5,c=0,t=21,pt=0,l=3:1.4'
2014.11.21 21:02:06 5: MYSENSORS gateway gateway: read: 103-103-0 s=5,c=0,t=21,pt=0,l=3:1.4
2014.11.21 21:02:06 5: MYSENSORS Read: Rx: fr=103 ci=005 c=000(C_PRESENTATION) st=021(S_WATER ) ack=0 '1.4'
2014.11.21 21:02:06 5: MYSENSORS/RAW: 0;0;3;0;9;re/ad: 103-103-0 s=5,c=2,t=24,pt=0,l=3:1.4
103;5;2;0;24;1.4
2014.11.21 21:02:06 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'read: 103-103-0 s=5,c=2,t=24,pt=0,l=3:1.4'
2014.11.21 21:02:06 5: MYSENSORS gateway gateway: read: 103-103-0 s=5,c=2,t=24,pt=0,l=3:1.4
2014.11.21 21:02:06 5: MYSENSORS Read: Rx: fr=103 ci=005 c=002(C_REQ ) st=024(V_VAR1 ) ack=0 '1.4'
Configuration for device 103 in fhem.cfg (added manually):
define Vatten MYSENSORS_DEVICE 103
attr Vatten IODev gateway
attr Vatten verbose 5
Cheers!
/ Thomas
Hallo an alle :-)
nur kurze Rückmeldung, mit den Dual-Switch und der Knopfzelle CR2032.
Start: 3,1V CR2032 am 21.11.2014 / 23:30 Uhr
Jetzt: 2,9V nach 8 Tagen
Bin mal gespannt, ob er immer noch die Probleme dann macht, wenn die Spannung an die 2,7V ran kommt.
Ich denke das ist dann evt. in 14 Tagen erreicht.
und dann willst alle 3 Wochen die Batterie wechseln ? :-) Ich versuchs grad mit 4 Batterien, Arduino Mini 3.3V mit dem integrierten Spannungsregler, hab jetzt seit 5 Tagen Batterie 102%, sollte ich wohl anpassen das es wenigstens unter 100% sind :-)
@Klaus0815
warum? Wenn ich jetzt davon ausgehe, das ich 200mV Spannungsabfall in 8 Tagen habe und wenn die Abschaltung jetzt bei 1,8V fehlerfrei funktioniert, komme ich optimistisch gesehen auf 2,5 - 3 Monate. Ist zwar noch nicht das wo ich hin will aber wenn das Gehäuse sehr klein ausfallen muß, hast du nicht wirklich alternativen, wo das Preis-/Leistungungsverhältnis noch stimmt.
Aber das ist ja auch nur erst einmal ein Testlauf ....
Momentan mache ich mir über Alternativen Gedanken, wo die Gehäusegröße keine Rolle spielt.
;D Ja und wenn ich eine Autobatterie daran hänge, dann komme ich auch ewig weit, wenn die Selbstentladung nicht wäre und die Gardienenstange die aushalten würde ::)
Bei den Test, welchen ich durchführen wollte, ging es darum, zu testen wie weit man die ganze Geschichte minimieren könnte und wie dann noch die Laufzeit ist, denn Theorie und Praxis sind zwei verschiedene paar Schuhe. ;D
Zitat von: Aloha am 21 November 2014, 21:07:52
/opt/fhem $ no reading-mapping for childId 5, type value1 at ./FHEM/10_MYSENSORS_DEVICE.pm line 530.
Zitat von: Aloha am 21 November 2014, 21:07:52
2014.11.21 21:02:06 5: MYSENSORS Read: Rx: fr=103 ci=005 c=000(C_PRESENTATION) st=021(S_WATER ) ack=0 '1.4'
[...]
2014.11.21 21:02:06 5: MYSENSORS Read: Rx: fr=103 ci=005 c=002(C_REQ ) st=024(V_VAR1 ) ack=0 '1.4'
Hi Thomas,
you seem to use an outdated version of the MySensors-module. Water-sensor is supported since Oct 25. 2014, the type of crash you see has been fixed by the commit of Nov 11. 2014 7:59pm.
regards,
Norbert
Hallo,
vermutlich habe ich etwas überlesen... aber ich kann nirgendwo den fehler finden warum meine MYSENSORS noden nicht aktualisiert werden, sie wurden hinzugefügt, senden fleißig das gateway empfängt aber die werte im FHEM bleiben gleich...
tja, solange Du uns nichts über die Config verrätst und ein aussagekräftiges log postest wird das vermutlich auch so bleiben...
Ok, ich benutze das ethernet gateway in der angepassten version was her gepostet wurde das keine probleme beim reconnect haben sollte.
die beiden sensoren sind DHT11 also feuchtigkeit temperatur.
wurden beide erkannt und als ID 20 und ID 100 angelegt.
im log ist leider nix zu sehen seid der autogenerierung ist auf dem log nix zu sehen
log: attr verbose an allen beteiligten devices auf 5.
config = fhem.cfg
danke für den tip.
da sind zwei sachen die sich mir nicht erschliessen, in der übersicht werden die Sensoren wie folgt angezeigt:
MYSENSORS_DEVICE
MYSENSOR_100
???
MYSENSOR_20
???
und lt dem log startet er alles liest die sensoren und nach ein paar mal ist dann einfach schluss...
2014.12.06 15:18:03 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=014(I_STARTUP_COMPLETE) ack=0 'Gateway startup complete.'
2014.12.06 15:18:03 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=002(I_VERSION ) ack=0 '1.4'
2014.12.06 15:18:07 5: MYSENSORS/RAW: /100;0;1;0;1;41.7
2014.12.06 15:18:07 5: MYSENSORS Read: Rx: fr=100 ci=000 c=001(C_SET ) st=001(V_HUM ) ack=0 '41.7'
2014.12.06 15:18:41 5: MYSENSORS/RAW: /100;0;1;0;1;42.0
2014.12.06 15:18:41 5: MYSENSORS Read: Rx: fr=100 ci=000 c=001(C_SET ) st=001(V_HUM ) ack=0 '42.0'
2014.12.06 15:19:00 5: MYSENSORS/RAW: /20;0;1;0;1;41.0
2014.12.06 15:19:00 5: MYSENSORS Read: Rx: fr=020 ci=000 c=001(C_SET ) st=001(V_HUM ) ack=0 '41.0'
ist die frage so dämlich das keiner antwortet? :-\
wenn Du mal die von mir angefragte config ( = fhem.cfg) posten würdest, dann könnte man Dir auch was qualifiziertes antworten.
sorry... das hab ich überlesen...
attr global userattr devStateIcon devStateStyle icon sortby webCmd widgetOverride
attr global autoload_undefined_devices 1
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath .
attr global motd SecurityCheck:\
\
WEB,WEBphone,WEBtablet has no basicAuth attribute.\
telnetPort has no password/globalpassword attribute.\
\
Restart FHEM for a new check if the problem is fixed,\
or set the global attribute motd to none to supress this message.\
attr global statefile ./log/fhem.save
attr global updateInBackground 1
attr global verbose 5
define telnetPort telnet 7072 global
define WEB FHEMWEB 8083 global
define WEBphone FHEMWEB 8084 global
attr WEBphone stylesheetPrefix smallscreen
define WEBtablet FHEMWEB 8085 global
attr WEBtablet stylesheetPrefix touchpad
# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%m.log fakelog
define autocreate autocreate
attr autocreate filelog ./log/%NAME-%Y.log
define eventTypes eventTypes ./log/eventTypes.txt
# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
define gateway MYSENSORS 192.168.88.111:5003
attr gateway requestAck 1
attr gateway stateFormat connection
attr gateway verbose 5
define MYSENSOR_100 MYSENSORS_DEVICE 100
attr MYSENSOR_100 IODev gateway
attr MYSENSOR_100 mapReading_humidity 0 humidity
attr MYSENSOR_100 mapReading_temperature1 1 temperature
attr MYSENSOR_100 mode node
attr MYSENSOR_100 verbose 5
attr MYSENSOR_100 version 1.4
define MYSENSOR_20 MYSENSORS_DEVICE 20
attr MYSENSOR_20 IODev gateway
attr MYSENSOR_20 mapReading_humidity 0 humidity
attr MYSENSOR_20 mapReading_temperature1 1 temperature
attr MYSENSOR_20 mode node
attr MYSENSOR_20 verbose 5
attr MYSENSOR_20 version 1.4
define relay MYSENSORS_DEVICE 101
attr relay IODev gateway
attr relay setCommands on:switch_1:on off:switch_1:off
attr relay stateFormat switch_1
Deine config sieht soweit korrekt aus.
Wenn z.B. eine Message wie diese hier reinkommt:
2014.12.06 15:18:07 5: MYSENSORS/RAW: /100;0;1;0;1;41.7
2014.12.06 15:18:07 5: MYSENSORS Read: Rx: fr=100 ci=000 c=001(C_SET ) st=001(V_HUM ) ack=0 '41.7'
Dann sollte beim Device MYSENSOR_100 das Reading 'humidity' den Wert '41.7' annehmen. Das sieht man aber nicht in der Übersicht (dafür müsste man für das Device noch das 'stateFormat (http://fhem.de/commandref.html#stateFormat)'-Attribut passend definieren), sondern erst mal nur in den Device-details. Das Stateformat läßt sich beim Autocreate schlecht automatisch setzen, da die MySensors-nodes typischerweise ja mehrere Readings haben.
Gruß,
Norbert
das merkwürdige ist, das irgendwann unvermittelt das ganze stoppt und keine Aktualisierungen ,mehr gemacht werden, das Gateway liest immer noch die werte der Sensoren aber der log zeigt nix mehr an, und das ohne jede Fehlermeldung...
ich hab das jetzt fünf mal gelesen aber immer nich nicht verstanden, gibt es da eventuell irgendwo ein Beispiel?
"stateFormat
Ändert den Gerätestatus, dies ist z.Bsp. in der Ausgabe des list Kommandos zu sehen, oder in der Raumübersicht von FHEMWEB. Falls nicht gesetzt, dann wird das state Reading übernommen. Sonst werden alle Wörter im Wert des Attributes durch das entsprechende Reading des Gerätes ersetzt (soweit vorhanden). Falls der Wert in {} eingeschlossen ist, dann wird es als Perl Ausdruck ausgewertet. Die Auswertung passiert bei jeder Änderung eines Readings."
Zitat von: nicepix4u am 09 Dezember 2014, 19:40:24
das merkwürdige ist, das irgendwann unvermittelt das ganze stoppt und keine Aktualisierungen ,mehr gemacht werden, das Gateway liest immer noch die werte der Sensoren aber der log zeigt nix mehr an, und das ohne jede Fehlermeldung...
was passiert denn in der Situation, wenn Du einen der Sensoren durchstartest (fhem und gateway unverändert)?
nix, irgendwann stoppt FHEM mit dem update der sensoren. damit das wieder startet muss ich shutdown restart machen sensor aus gateway aus bringt alles nix, das trebit mich zum wahnsinn weil keine fehlermeldung kommt nix, einfach schluss
sieht immer etwas so aus:
2014.12.10 07:59:05 5: SW: 303b303b333b303b323b0a
2014.12.10 07:59:05 5: MYSENSORS/RAW: /0;0;3;0;2;1.4
2014.12.10 07:59:05 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=002(I_VERSION ) ack=0 '1.4'
2014.12.10 07:59:10 5: MYSENSORS/RAW: /100;0;1;0;1;29.3
2014.12.10 07:59:10 5: MYSENSORS Read: Rx: fr=100 ci=000 c=001(C_SET ) st=001(V_HUM ) ack=0 '29.3'
2014.12.10 07:59:18 5: MYSENSORS/RAW: /20;0;1;0;1;45.0
2014.12.10 07:59:18 5: MYSENSORS Read: Rx: fr=020 ci=000 c=001(C_SET ) st=001(V_HUM ) ack=0 '45.0'
2014.12.10 07:59:44 5: MYSENSORS/RAW: /100;0;1;0;1;29.0
2014.12.10 07:59:44 5: MYSENSORS Read: Rx: fr=100 ci=000 c=001(C_SET ) st=001(V_HUM ) ack=0 '29.0'
2014.12.10 08:00:18 5: MYSENSORS/RAW: /100;0;1;0;1;29.1
2014.12.10 08:00:18 5: MYSENSORS Read: Rx: fr=100 ci=000 c=001(C_SET ) st=001(V_HUM ) ack=0 '29.1'
Hängt Dein Gateway am Ethernet? Dann schließ doch parallel mal den Serial-monitor der Arduino-IDE an und schau, was das Gateway da sagt.
Ist jedenfalls so, dass solange die Verbindung zum Gateway noch steht die komplette Kommunikation der Sensorwerte vom Gateway ausgeht, FHEM empfängt dann nur - d.h. das FHEM-modul wird keine Fehlermeldung oder ähnliches ausgeben, wenn das Gateway einfach nix mehr empfängt, sondern einfach recht still werden.
Im MySensors-forum gibt's mehrere Threads wo Leute Probleme mit dem Zusammenspiel von Ethernet-modul und nRF24L01 haben.
Welcher Sketch genau läuft denn auf dem GateWay?
den seriellen monitopr hab ich immer an, das gateway empfängt ganz normal die werte nur das fhem nimt sie nicht mehr auf, ich werde morgen mal das serielle Gateway ausprobieren, ich hb den sketch drauf der hier in Thread veröffentlicht wurde mit verbessertem reconnect
Hallo Thomas,
wieviele (unterschiedliche) Sensoren hast du denn am Gateway angeschlossen?
Wird die Übertragung zu Fhem bei allen Sensoren gestoppt?
Mein Gateway läuft bei mir mit einem TFK-Sensor mittlerweile einwandfrei. Bei meiner letzten Version hat es wohl an der Batteriespannung gehakt, die war wohl nicht konstant. Probleme habe ich immer noch mit dem "Anlernen" von neuen Sensoren. Dann mache ich kurz einen Reset am Gateway, schalte den Inclusion-Modus ein und dann werden die in Fhem per autocreate aufgenommen. Klappt aber nicht immer, sondern muss den Vorgang öfter wiederholen. Aber wenn sie drin sind, funktionieren sie tadellos. Ich teste hier sporadisch mit Temperatursensoren DS18B20, Relay, Humidity, Distance und DoorWindow (Sleep)-Button.
Die im MySensors-Forum beschriebenen Netzprobleme (LAN) kann ich nicht (mehr) bestätigen seitdem ich die Büchse ordentlich zusammengelötet habe. Ich habe derzeitig den original Sketch drauf.
http://blog.moneybag.de/fhem-sensoren-an-fhem-mit-nrf24l01-transceiver/
LG
/robin
ich benötige noch ein paar zuverlässige Fenster und Tür Sensoren. Ich habe mir ein seriell Gateway und ein Door Window und Push Button Sensor zusammen gebaut. Trotzdem ich requestAck eingestellt habe wird das ein oder andere schalten nicht angezeigt. Muß da noch etwas an dem Beispiel sketch geändert werden damit der ack Mechanismus funktioniert ?
Hallo Thorsten,
ich habe den BinarySwitchButton-Sleep Sketch drauf, funktioniert bisher einwandfrei. Liegt es am Reed-Kontakt? Wird das Signal nicht zum Gateway übertragen?
LG
/robin
Hallo Robin,
der Betrag auf dem Blog bezieht sich auf das MQTT Gateway, ich benutze das normal Ethernet gateway, um die MQTT Brocker aus dem weg zugehen, oder benutzt du das auch Ohne MQTT ?
Gruß
Thomas
Hallo,
ich möchte von meinem Sensor einen "eigenen" Wert an FHEM übertragen. Im Logfile von FHEM kommt der auch an aber ich bekomme den nicht als Reading eingetragen.
2014.12.14 10:40:00 5: MYSENSORS gateway MYS_GW: read: 101-101-0 s=5,c=1,t=24,pt=7,l=5:814
2014.12.14 10:40:00 5: MYSENSORS/RAW: /101;5;1;0;24;814
2014.12.14 10:40:00 5: MYSENSORS Read: Rx: fr=101 ci=005 c=001(C_SET ) st=024(V_VAR1 ) ack=0 '814'
2014.12.14 10:40:00 4: MYSENSORS_DEVICE MYSENSOR_101: ignoring C_SET-message no reading-mapping for childId 5, type value1
Es handelt sich dabei um eine Akku-Spannung. Ich möchte nicht nur den Akku-Level sonder auch die Spannung wissen.
Wie kann ich den mir als Reading einbinden?
Vielen Dank
Bobby
Hallo!
Folgendes Problem:
Habe ein serielles Gateway an Fhem. Jetzt habe ich schon erfolgreich den RelayActuator umgesetzt und in Fhem eingebunden.
Nächster Schritt soll der RelayWithButtonActuator Code sein. Relais ist auf Port 3 des Arduinos.
Leider macht das Relais kein Mucks, obwohl das beim RelayActuator-Code noch funktioniert hat.
Die serielle Ausgabe vom RelayWithButtonActuator Code lautet:
Zitatread: 0-0-100 s=1,c=1,t=2,pt=0,l=1:1
read: 0-0-100 s=1,c=1,t=2,pt=0,l=1:0
read: 0-0-100 s=1,c=1,t=2,pt=0,l=1:1
wenn ich ein-aus-ein auf der Fhem-Konsole drücke. Eigentlich sollte das doch funktionieren, oder? Aber das Relais bewegt sich nicht...????
Was mache ich falsch???
Eingebunden ist es wie folgt:
define MYSENSOR_100 MYSENSORS_DEVICE 100
attr MYSENSOR_100 IODev gateway
attr MYSENSOR_100 mapReading_switch1 1 switch
attr MYSENSOR_100 mode repeater
attr MYSENSOR_100 setReading_switch1 on,off
attr MYSENSOR_100 version 1.4.1
attr MYSENSOR_100 setCommands on:switch1:on off:switch1:off
Nachtrag: Den Code vom Git genommen - jetzt funzt es.
https://github.com/mysensors/Arduino/blob/master/libraries/MySensors/examples/RelayWithButtonActuator/RelayWithButtonActuator.ino
jetzt habe ich bei einem Update von gestern auf zwei meiner Testmaschinen (Raspberry Pi) den gleichen Fehler.
014-12-23 21:55:42 Global global UPD FHEM/lib/Device/MySensors/Constants.pm
2014-12-23 21:55:42 Global global mv ./FHEM/lib/Device/MySensors/Constants.pm ./restoreDir/2014-12-23/FHEM/lib/Device/MySensors/Constants.pm failed:Permission denied, aborting the update
irgend jemand eine Idee?
LG
/robin
Hallo Robin,
Schau dir mal die Rechte der Datei an.
Gruß Stefan
Gesendet von meinem iPad mit Tapatalk HD
Root, owner auch root.
Die Rechte habe ich auch schon geändert auf 644, hat nix gebracht.
Ein mv durch owner fhem kommt einem schreiben und löschen gleich, was dem User fhem für eine Datei des users Root mit 644 nicht erlaubt ist.
Gib ihr doch mal 655 oder 777 ;-)
Lg
Stefan
Hab ich gestern auch gemacht für beide Dateien im lib,
Danach konnte das Update die beiden Dateien moven und die neuen schreiben.
Cu
777
UPD FHEM/lib/Device/MySensors/Constants.pm
mv ./FHEM/lib/Device/MySensors/Constants.pm ./restoreDir/2014-12-23/FHEM/lib/Device/MySensors/Constants.pm failed:Permission denied, aborting the update
Lösche doch beide einfach weg, dann hätte er auch nix zum mv.
hatte ich auch schon mal gemacht...
UPD FHEM/lib/Device/MySensors/Constants.pm
open ./FHEM/lib/Device/MySensors/Constants.pm failed: Permission denied, trying to restore the previous version and aborting the update
Ich hab gestern wegen dem HueModul Änderungen auch noch ein update Force gemacht.
update force macht er auch nicht, bleibt an der gleichen stelle hängen
Zitat von: fh168 am 23 Dezember 2014, 22:38:27
hatte ich auch schon mal gemacht...
UPD FHEM/lib/Device/MySensors/Constants.pm
open ./FHEM/lib/Device/MySensors/Constants.pm failed: Permission denied, trying to restore the previous version and aborting the update
Ach ja das Verzeichnis MySensors muss auch für den User fhem beschreibbar sein
und wie sagt man das dem System?
klappt! mc sei dank!
Und Dir auch vielen Dank!
chmod 655 /FHEM/lib/Device/MySensors
läuft!
bei hue was neues? ... ok andere Baustelle. hue hab ich auch.
Ja die subtypes der Devices wurde erweitert, hue Lampen sind jetzt als extcolordimmer definiert. usw.
Lg
schaue ich mir mal an
mehr zu den hue updates findest du hier:
http://forum.fhem.de/index.php/topic,11020.msg233471.html#msg233471 (http://forum.fhem.de/index.php/topic,11020.msg233471.html#msg233471)
http://forum.fhem.de/index.php/topic,11020.msg233648.html#msg233648 (http://forum.fhem.de/index.php/topic,11020.msg233648.html#msg233648)
http://forum.fhem.de/index.php/topic,30895.msg234449.html#msg234449 (http://forum.fhem.de/index.php/topic,30895.msg234449.html#msg234449)
gruss
andre
Ich bekomme keinen MySensor Client mehr gepairt?
Vorgehensweise:
1. inclusion-mode on
2. MySensor Client an Strom anschliessen
Nichts passiert. Meine drei anderen Clients gingen vor 1-2 Wochen ohne Problem zum Pairen... und laufen auch heute noch.
Gibt es eine Möglichkeit die Funktion des Gateways zu überprüfen?
Ich habe es folgendermaßen angelegt:
define gateway MYSENSORS /dev/ttyAMA0@115200
und im Log erhalte ich nur folgende Meldungen:
2015.03.05 16:31:38 3: Opening gateway device /dev/ttyAMA0
2015.03.05 16:31:39 3: Setting gateway baudrate to 115200
2015.03.05 16:31:39 3: gateway device opened
2015.03.05 16:31:39 1: usb create starting
2015.03.05 16:31:40 3: Probing TCM_ESP3 device /dev/ttyUSB0
2015.03.05 16:31:41 3: Probing TCM_ESP2 device /dev/ttyUSB0
2015.03.05 16:31:41 3: Probing FHZ device /dev/ttyUSB0
2015.03.05 16:31:41 3: Probing TRX device /dev/ttyUSB0
2015.03.05 16:31:42 3: Probing ZWDongle device /dev/ttyUSB0
2015.03.05 16:31:42 3: Probing FRM device /dev/ttyUSB0
2015.03.05 16:31:47 1: usb create end
Hi gloob,
am schnellsten geht es, wenn du auf dein Device (Gateway) gehst und "set inclusion-mode" auslöst.
Dann sollten die LEDs blinken (sofern du die beschaltet hast), kannst auch den loglevel auf 5 setzen und schauen was passiert.
Gruß Jens
Vielen Dank für die Info.
Scheinbar kommen schon ein paar Daten vom Sensor an.
2015.03.05 17:20:16 5: MYSENSORS/RAW: /0;0;3;0;9;r
2015.03.05 17:20:16 5: MYSENSORS/RAW: 0;0;3;0;9;r/ead: 222-222-0 s=0,c=1,t=23,pt=2,l=2:56
222;0
2015.03.05 17:20:16 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'read: 222-222-0 s=0,c=1,t=23,pt=2,l=2:56'
2015.03.05 17:20:16 5: MYSENSORS gateway gateway: read: 222-222-0 s=0,c=1,t=23,pt=2,l=2:56
2015.03.05 17:20:16 5: MYSENSORS/RAW: 222;0/;1;0;23;56
2015.03.05 17:20:16 5: MYSENSORS Read: Rx: fr=222 ci=000 c=001(C_SET ) st=023(V_LIGHT_LEVEL ) ack=0 '56'
2015.03.05 17:20:16 3: MYSENSORS: ignoring set-msg from unknown radioId 222, childId 0 for V_LIGHT_LEVEL
Hast du vielleicht noch einen Tipp für mich wie ich mir den Wert in einem Raum anzeigen lassen kann?
Vielen Dank für die Unterstützung eines Neulings :)
Gruß
Stefan
Edit: Hab es mit ein bisschen Google und einer readingsGroup hinbekommen. Vielen Dank für die Hilfe trotzdem.
Hi gloob,
wenn du noch eine Frage hast, kann ich sie dir gerne heute (Freitag) so gegen 15:00 Uhr beantworten (soweit ich die Anwort weiß) ;D
Gruß Jens
Zitat von: ntruchsess am 16 November 2014, 21:14:10
Wenn man keinen der Standard-sketches verwendet, dann kennt das Modul keine sinnvollen Defaults. Kann man aber über die Attribute komplett selber konfigurieren. Um Werte an Aktoren zu schicken verwendet man die Attribute 'setCommands' und 'setReading' (http://fhem.de/commandref.html#MYSENSORS_DEVICE).
Gibt es hier schon weitere Erkenntnisse?
Ich würde auch gerne Werte an einen Node schicken und diese per LCD darstellen (Verschiedene Temperaturen etc.)
Hallo Zusammen. :)
Ich habe mich nun auch mit den MySensors beschäftigt und heute Nachmittag das Serial Gateway und einen Temperatur Node zum Test aufgebaut. Leider bekomme ich es nicht hin, dass die Node per AutoCreate in Fhem angelegt wird. Ich kann mir leider auch nicht erklären woran es liegt, weil sowohl das Gateway als auch die Node vernünftig über den Serial Monitor Daten ausgeben.
Serial Gateway über Serial Monitor:
0;0;3;0;14;Gateway startup complete.
0;0;3;0;9;read: 0-0-0 s=255,c=0,t=17,pt=0,l=5:1.4.1
0;255;0;0;17;1.4.1
0;0;3;0;9;read: 0-0-0 s=255,c=3,t=6,pt=1,l=1:0
0;0;3;0;9;read: 0-0-0 s=255,c=3,t=11,pt=0,l=18:Temperature Sensor
0;0;3;0;9;read: 0-0-0 s=255,c=3,t=12,pt=0,l=3:1.0
0;0;3;0;9;read: 0-0-0 s=0,c=0,t=6,pt=0,l=5:1.4.1
0;0;0;0;6;1.4.1
0;0;3;0;9;read: 0-0-0 s=0,c=1,t=0,pt=7,l=5:74.8
0;0;1;0;0;74.8
Node über Serial Monitor:
sensor started, id 0
send: 0-0-0-0 s=255,c=0,t=17,pt=0,l=5,st=ok:1.4.1
send: 0-0-0-0 s=255,c=3,t=6,pt=1,l=1,st=ok:0
send: 0-0-0-0 s=255,c=3,t=11,pt=0,l=18,st=ok:Temperature Sensor
send: 0-0-0-0 s=255,c=3,t=12,pt=0,l=3,st=ok:1.0
send: 0-0-0-0 s=0,c=0,t=6,pt=0,l=5,st=ok:1.4.1
send: 0-0-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:75.0
Alleine die ID der Node stört mich... Das Gateway ist folgendermaßen in Fhem definiert:
define MySensors MYSENSORS /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A504800O-if00-port0
attr MySensors autocreate 1
attr MySensors group Gateways
attr MySensors icon cul_usb
attr MySensors requestAck 1
attr MySensors room System
attr MySensors stateFormat connection
attr MySensors verbose 5
Fhem empfängt das Folgende, wenn die Node sendet:
2015.03.17 18:58:57 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A504800O-if00-port0 disconnected, waiting to reappear (MySensors)
2015.03.17 19:11:36 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A504800O-if00-port0 reappeared (MySensors)
2015.03.17 19:11:36 5: MYSENSORS send: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=002(I_VERSION ) ack=0 ''
2015.03.17 19:11:36 5: SW: 303b303b333b303b323b0a
2015.03.17 19:11:37 5: MYSENSORS/RAW: /�
2015.03.17 19:12:15 5: MYSENSORS/RAW: �/�
2015.03.17 19:12:15 5: MYSENSORS/RAW: ��/�
2015.03.17 19:12:17 5: MYSENSORS/RAW: ���/����
2015.03.17 19:12:17 5: MYSENSORS/RAW: �������/�
2015.03.17 19:12:28 5: MYSENSORS/RAW: ��������/�
2015.03.17 19:12:28 5: MYSENSORS/RAW: ���������/�
2015.03.17 19:12:30 5: MYSENSORS/RAW: ����������/�
2015.03.17 19:12:30 5: MYSENSORS/RAW: �����������/�
2015.03.17 19:12:30 5: MYSENSORS/RAW: ������������/�
2015.03.17 19:12:30 5: MYSENSORS/RAW: �������������/�
2015.03.17 19:12:31 5: MYSENSORS/RAW: ��������������/�
Folgendes über Fhem mit Inclusion Mode über das Web Interface:
2015.03.17 19:24:49 5: MYSENSORS send: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=005(I_INCLUSION_MODE) ack=0 '1'
2015.03.17 19:24:49 5: SW: 303b303b333b303b353b310a
2015.03.17 19:24:53 5: MYSENSORS/RAW: ������������ర�5���ߠ������/�
2015.03.17 19:24:53 5: MYSENSORS/RAW: ������������ర�5���ߠ�������/�
2015.03.17 19:24:55 5: MYSENSORS/RAW: ������������ర�5���ߠ��������/�
2015.03.17 19:24:55 5: MYSENSORS/RAW: ������������ర�5���ߠ���������/�
2015.03.17 19:24:55 5: MYSENSORS/RAW: ������������ర�5���ߠ����������/�
2015.03.17 19:24:56 5: MYSENSORS/RAW: ������������ర�5���ߠ�����������/�
Möglicherweise nutze ich auch den falschen Sketch für das Gateway. Welchen nutzt ihr? Wäre toll, wenn mir jemand helfen könnte.
Sketch ist bestimmt in Ordnung. Die Rate vermuttlich nicht. Füge @115200 zu der Gateway-Definition.
Danke für deine Hilfe! Du hattest Recht. :)
Nun wird mir die Temperatur angezeigt, allerdings in Fahrenheit. Lässt sich das beheben?
Ich habe auch noch eine Frage zum Sketch. Ich nutze den normalen Sketch von hier:
http://www.mysensors.org/build/serial_gateway (http://www.mysensors.org/build/serial_gateway)
Muss ich diese Änderung im Sketch vornehmen?
// To start gateway with include button and led blinking functionality use this constructor
Gateway gw(9, 10, INCLUSION_MODE_TIME, INCLUSION_MODE_PIN, 6, 5, 4);
Kommt mir bekannt vor...
Ich meine, beim Include fragt der Sensor auch nach dem gewünschten Format (metric oder imperial) und speichert im EEPROM. Mit Gateway-Sketch hat das wenig zu tun. Ich weiß nicht mehr genau, wie das gesteuert wird. Du kannst das aber leicht in Deinem Sensor-Sketch behandelt. Da muss irgendwas stehen in der Art metric = gw.getConfig(...).
Was steht in deinem Sketch?
boolean metric = true
oder
boolean metric = false
Gruß
Stefan
Bei mir steht
boolean metric = true;
im Sketch. Habe gestern auch mal versucht den DallasTemperatureSensor Sketch mit dem Battery Sketch zu verbinden. Beim Kompilieren bekomme ich auch keine Fehler. Im Serial Monitor wird auch die Batteriespannung ausgegeben, aber leider kommt in FHEM nicht davon an.
sensor started, id 0
send: 0-0-0-0 s=255,c=0,t=17,pt=0,l=5,st=ok:1.4.1
send: 0-0-0-0 s=255,c=3,t=6,pt=1,l=1,st=ok:0
send: 0-0-0-0 s=255,c=3,t=11,pt=0,l=18,st=ok:Temperature Sensor
send: 0-0-0-0 s=255,c=3,t=12,pt=0,l=3,st=ok:1.0
send: 0-0-0-0 s=255,c=3,t=11,pt=0,l=13,st=ok:Battery Meter
send: 0-0-0-0 s=255,c=3,t=12,pt=0,l=3,st=ok:1.0
send: 0-0-0-0 s=0,c=0,t=6,pt=0,l=5,st=ok:1.4.1
send: 0-0-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:84.4
1023
Battery Voltage: 3.44 V
Battery percent: 102 %
send: 0-0-0-0 s=255,c=3,t=0,pt=1,l=1,st=ok:102
Habe ich möglicherweise doch eine Fehler im Sketch:
// Example sketch showing how to send in OneWire temperature readings
#include <MySensor.h>
#include <SPI.h>
#include <DallasTemperature.h>
#include <OneWire.h>
#define ONE_WIRE_BUS 3 // Pin where dallase sensor is connected
#define MAX_ATTACHED_DS18B20 16
unsigned long SLEEP_TIME = 300000; // Sleep time between reads (in milliseconds)
OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);
MySensor gw;
float lastTemperature[MAX_ATTACHED_DS18B20];
int numSensors=0;
int BATTERY_SENSE_PIN = A0; // select the input pin for the battery sense point
int oldBatteryPcnt = 0;
boolean receivedConfig = false;
boolean metric = true;
// Initialize temperature message
MyMessage msg(0,V_TEMP);
void setup()
{
// Startup OneWire
sensors.begin();
// use the 1.1 V internal reference
analogReference(INTERNAL);
// Startup and initialize MySensors library. Set callback for incoming messages.
gw.begin();
// Send the sketch version information to the gateway and Controller
gw.sendSketchInfo("Temperature Sensor", "1.0");
gw.sendSketchInfo("Battery Meter", "1.0");
// Fetch the number of attached temperature sensors
numSensors = sensors.getDeviceCount();
// Present all sensors to controller
for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {
gw.present(i, S_TEMP);
}
}
void loop()
{
// Process incoming messages (like config from server)
gw.process();
// Fetch temperatures from Dallas sensors
sensors.requestTemperatures();
// Read temperatures and send them to controller
for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {
// Fetch and round temperature to one decimal
float temperature = static_cast<float>(static_cast<int>((gw.getConfig().isMetric?sensors.getTempCByIndex(i):sensors.getTempFByIndex(i)) * 10.)) / 10.;
// Only send data if temperature has changed and no error
if (lastTemperature[i] != temperature && temperature != -127.00) {
// Send in the new temperature
gw.send(msg.setSensor(i).set(temperature,1));
lastTemperature[i]=temperature;
}
}
{
// get the battery Voltage
int sensorValue = analogRead(BATTERY_SENSE_PIN);
Serial.println(sensorValue);
// 1M, 470K divider across battery and using internal ADC ref of 1.1V
// Sense point is bypassed with 0.1 uF cap to reduce noise at that point
// ((1e6+470e3)/470e3)*1.1 = Vmax = 3.44 Volts
// 3.44/1023 = Volts per bit = 0.003363075
float batteryV = sensorValue * 0.003363075;
int batteryPcnt = sensorValue / 10;
Serial.print("Battery Voltage: ");
Serial.print(batteryV);
Serial.println(" V");
Serial.print("Battery percent: ");
Serial.print(batteryPcnt);
Serial.println(" %");
if (oldBatteryPcnt != batteryPcnt) {
// Power up radio after sleep
gw.sendBatteryLevel(batteryPcnt);
oldBatteryPcnt = batteryPcnt;
}
gw.sleep(SLEEP_TIME);
}
}
Was steht in deinem Sketch?
boolean metric = true
oder
boolean metric = false
Gruß
Stefan
Bei mir steht
boolean metric = true;
im Sketch.
Wie oben beschrieben. :D
gw.sendSketchInfo("Temperature Sensor", "1.0");
gw.sendSketchInfo("Battery Meter", "1.0");
Das sieht für mich doppelt aus, keine Ahnung ob deswegen was durcheinander kommt.
Außerdem nutzt Du beim Sensor auslesen nicht Deinen boolean sondern:
float temperature = static_cast<float>(static_cast<int>((gw.getConfig().isMetric?sensors.getTempCByIndex(i):sensors.getTempFByIndex(i)) * 10.)) / 10.;
Das erklärt zumindest die Fahrenheit-Werte. Das sollte wohl eher so heißen:
float temperature = static_cast<float>(static_cast<int>((metric?sensors.getTempCByIndex(i):sensors.getTempFByIndex(i)) * 10.)) / 10.;
Vielen Dank! Nun zeigt der Sensor mir die Temperaturwerte in Celsius an.
Die eine Zeile habe ich aus dem Sketch gelöscht. Dies bringt jedoch keine Besserung.
Möglicherweise liegt es daran dass FHEM die Reading nicht konkret zu ordnen kann. Im Log kann ich diese nämlich sehen.
Muss man die Batteriewerte dem Sensor manuell zu teilen oder geschieht dies automatisch?
Die Batteriewerte musst Du natürlich manuell senden. SketchInfo brauchst Du dafür nicht.
gw.sendBatteryLevel(batteryPcnt); sollte reichen. Dabei wird Message I_BATTERY_LEVEL als C_INTERNAL gesendet. Habe leider keinen Batteriesensor uns kann gerade keinen aufbauen/emulieren.
Kannst Du etwa in Log sehen? Da sollte beim Empfang solcher Meldungen folgendes ausgeführt werden:
Log3 ($name,4,"MYSENSORS_DEVICE $name: batterylevel $msg->{payload}");
Die Batteriewerte werden von meinem Sketch gesendet. Ich übertrage zusätzlich auch die Spannung:
gw.sendBatteryLevel(batteryPcnt);
gw.sendBatteryLevel(batteryV);
Folgendes wird von FHEM empfangen:
2015.03.18 19:34:47 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'read: 0-0-0 s=0,c=1,t=0,pt=7,l=5:22.4'
2015.03.18 19:34:47 5: MYSENSORS gateway MySensors: read: 0-0-0 s=0,c=1,t=0,pt=7,l=5:22.4
2015.03.18 19:34:47 5: MYSENSORS Read: Rx: fr=000 ci=000 c=001(C_SET ) st=000(V_TEMP ) ack=0 '22.4'
2015.03.18 19:34:47 5: MYSENSORS/RAW: /0;0;3;0;9;read: 0-0-0 s=255,c=3,t=0,pt=1,l=1:102
0;0;3;0;9;read: 0-0-0 s=255,c=3,t=0,pt=1,l=1:3
2015.03.18 19:34:47 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'read: 0-0-0 s=255,c=3,t=0,pt=1,l=1:102'
2015.03.18 19:34:47 5: MYSENSORS gateway MySensors: read: 0-0-0 s=255,c=3,t=0,pt=1,l=1:102
2015.03.18 19:34:47 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'read: 0-0-0 s=255,c=3,t=0,pt=1,l=1:3'
2015.03.18 19:34:47 5: MYSENSORS gateway MySensors: read: 0-0-0 s=255,c=3,t=0,pt=1,l=1:3
Soweit ich das nachvollziehen kann, empfängt Fhem doch hier die Temperatur von 22.4 °C, den Batteriestand von 102% und auch die Batteriespannung von 3V. Automatisch angelegt wird jedoch nur das Temperatur Reading. Habe die Sensor auch schon öfters gelöscht und neu hinzugefügt. Es bleibt aber ausschließlich beim Temperatur Reading.
Edit: So ganz stimmt die Spannung jedoch nicht. Laut Messgerät sind es nur 2,92 V.
Zwei mal verschiedene Werte mit der Methode sendBatteryLevel zu senden macht keinen Sinn. ABer daran wird es wohl nicht liegen. Deine Meldung kommt irgendwie mit dem Typ I_LOG_MESSAGE (9) statt I_BATTERY_LEVEL (0). Habe leider keine Ahnung, warum das passiert.
Hi hexenmeister, mal eine andere Frage zu MySensors :-)
Habt ihr das Modul jetzt auch über die Update-Funktion von FHEM eingecheckt?
Der Probelauf ist doch positiv verlaufen :-)
Gruß Jens
Norbert hat das Modul schon lange in die FHEM-Repository eingecheckt.
Zitat von: hexenmeister am 18 März 2015, 20:30:12
Zwei mal verschiedene Werte mit der Methode sendBatteryLevel zu senden macht keinen Sinn. ABer daran wird es wohl nicht liegen. Deine Meldung kommt irgendwie mit dem Typ I_LOG_MESSAGE (9) statt I_BATTERY_LEVEL (0). Habe leider keine Ahnung, warum das passiert.
Dann werde ich einen Wert wieder löschen. Du liegst damit richtig, dass sich nichts ändert. Stefan hatte vor längerer Zeit nachfolgenden Sketch gepost:
Zitat von: Porky666 am 29 Oktober 2014, 16:08:04
Hallo Zusammen,
da ich die Mysensor Nodes mit Batterie betreibe, habe ich natürlich auch ein Bedarf ein Reading oder 2 mit dem Batterielevel empfangen zu können.
Nun auf [url]http://mysensors.org/build/battery[url] gibt es den Hinweis mit einem einfachen Spannungsteiler über einen Analogen Eingang (A0) die Spannung zu überwachen.
Ich habe das dort verlinkte Batterysensor.ino von Github mal mit dem Humiditysensor.ino gemergt -- aufgespielt und getestet.
Funktioniert mit deinem im FHEM ankommenden Reading Batterylevel als % Angabe. Das kann man auch varirieren mit Battery in Volt oder beides. Vielleicht passts Euch ja.
#include <SPI.h>
#include <MySensor.h>
#include <DHT.h>
#define CHILD_ID_HUM 0
#define CHILD_ID_TEMP 1
int BATTERY_SENSE_PIN = A0;
#define HUMIDITY_SENSOR_DIGITAL_PIN 3
unsigned long SLEEP_TIME = 900000; // Sleep time between reads (in milliseconds)
int oldBatteryPcnt = 0;
MySensor gw;
DHT dht;
float lastTemp;
float lastHum;
boolean metric = true;
MyMessage msgHum(CHILD_ID_HUM, V_HUM);
MyMessage msgTemp(CHILD_ID_TEMP, V_TEMP);
void setup()
{
analogReference(INTERNAL);
gw.begin();
dht.setup(HUMIDITY_SENSOR_DIGITAL_PIN);
// Send the Sketch Version Information to the Gateway
gw.sendSketchInfo("Humidity", "1.0");
// Register all sensors to gw (they will be created as child devices)
gw.present(CHILD_ID_HUM, S_HUM);
gw.present(CHILD_ID_TEMP, S_TEMP);
metric = gw.getConfig().isMetric;
}
void loop()
{
delay(dht.getMinimumSamplingPeriod());
float temperature = dht.getTemperature();
if (isnan(temperature)) {
Serial.println("Failed reading temperature from DHT");
} else if (temperature != lastTemp) {
lastTemp = temperature;
if (!metric) {
temperature = dht.toFahrenheit(temperature);
}
gw.send(msgTemp.set(temperature, 1));
Serial.print("T: ");
Serial.println(temperature);
}
float humidity = dht.getHumidity();
if (isnan(humidity)) {
Serial.println("Failed reading humidity from DHT");
} else if (humidity != lastHum) {
lastHum = humidity;
gw.send(msgHum.set(humidity, 1));
Serial.print("H: ");
Serial.println(humidity);
}
{
// get the battery Voltage
int sensorValue = analogRead(BATTERY_SENSE_PIN);
Serial.println(sensorValue);
// 1M, 470K divider across battery and using internal ADC ref of 1.1V
// Sense point is bypassed with 0.1 uF cap to reduce noise at that point
// ((1e6+470e3)/470e3)*1.1 = Vmax = 3.44 Volts
// 3.44/1023 = Volts per bit = 0.003363075
float batteryV = sensorValue * 0.003363075;
int batteryPcnt = sensorValue / 10;
Serial.print("Battery Voltage: ");
Serial.print(batteryV);
Serial.println(" V");
Serial.print("Battery percent: ");
Serial.print(batteryPcnt);
Serial.println(" %");
if (oldBatteryPcnt != batteryPcnt) {
// Power up radio after sleep
gw.sendBatteryLevel(batteryPcnt);
oldBatteryPcnt = batteryPcnt;
}
gw.sleep(SLEEP_TIME); //sleep a bit
}}
Gruß
Stefan und Danke für die Prima Arbeit an dem Modul !
Funktioniert dieser Sketch noch bei dir, Stefan?
Bei mir klappt es auch mit diesem Sketch nicht. Alles wird angelegt, nur das Batterie Reading nicht. Allerdings finden sich wieder exakt die gleichen Meldungen im Log:
2015.03.18 22:08:03 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'read: 0-0-0 s=255,c=3,t=0,pt=1,l=1:102'
2015.03.18 22:08:03 5: MYSENSORS gateway MySensors: read: 0-0-0 s=255,c=3,t=0,pt=1,l=1:102Hat sich möglicherweise irgendwas an den Modulen geändert? Es wird wohl kaum an dem Arduino Nano liegen den ich zum Testen nutze, oder?
Wie gesagt, ich verstehe nicht auf Anhieb, was hier falsch läuft. Ich müsste mal eine Sensor und einen Gateway nachbauen und schauen, was und wo ankommt. Komme leider in der nächsten Zeit nicht dazu. Ich glaube nicht, dass der Sensor etwas falsch sendet. Schon eher wird das in GateWay nicht richtig weitergeleitet. Evtl. liegt hier ein Mißverständnis der Funktion in dem Gateway und dem FHEM-Modul.
Kannst Du mal loggen, was Gateway auf Seriel ausgibt für die Bat.-Meldungen? Also ohne an FHEM angeschlossen zu sein.
Dann sehen wir, ob die Meldungen in dem Modul (glaube ich eher nicht) oder im Gateway als LOG-Message "umdefiniert".
P.S. Auch die seriellen Ausgaben des Sensors wären interessant.
Ich hoffe, dass du mit den seriellen Ausgaben, die Ausgabe über den SerialMonitor meintest. Habe es gerade mal nacheinander getestet:
Gateway:
0;0;3;0;14;Gateway startup complete.
0;0;3;0;9;read: 0-0-0 s=255,c=0,t=17,pt=0,l=5:1.4.1
0;255;0;0;17;1.4.1
0;0;3;0;9;read: 0-0-0 s=255,c=3,t=6,pt=1,l=1:0
0;0;3;0;9;read: 0-0-0 s=255,c=3,t=11,pt=0,l=18:Temperature Sensor
0;0;3;0;9;read: 0-0-0 s=255,c=3,t=12,pt=0,l=3:1.0
0;0;3;0;9;read: 0-0-0 s=0,c=0,t=6,pt=0,l=5:1.4.1
0;0;0;0;6;1.4.1
0;0;3;0;9;read: 0-0-0 s=0,c=1,t=0,pt=7,l=5:22.3
0;0;1;0;0;22.3
0;0;3;0;9;read: 0-0-0 s=255,c=3,t=0,pt=1,l=1:102
Sensor:
sensor started, id 0
send: 0-0-0-0 s=255,c=0,t=17,pt=0,l=5,st=ok:1.4.1
send: 0-0-0-0 s=255,c=3,t=6,pt=1,l=1,st=ok:0
send: 0-0-0-0 s=255,c=3,t=11,pt=0,l=18,st=ok:Temperature Sensor
send: 0-0-0-0 s=255,c=3,t=12,pt=0,l=3,st=ok:1.0
send: 0-0-0-0 s=0,c=0,t=6,pt=0,l=5,st=ok:1.4.1
send: 0-0-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:22.5
1023
Battery Voltage: 3.44 V
Battery percent: 102 %
send: 0-0-0-0 s=255,c=3,t=0,pt=1,l=1,st=ok:102
Aus meiner Sicht sind die Batterie-Meldungen in Sensor und auch in Gateway korrekt. Die Ursache liegt wahrscheinlich in dem FHEM-Modul.
Die Methode MYSENSORS::DEVICE::onInternalMessage scheint nur dann aufgerufen zu werden (in onInternalMsg), wenn die Meldung nicht an/von Gateway gesendet wird. Das ist hier jedoch genau der Fall. So zumindest beim schnellen Durchsehen.
Hier solle Norbert das Modul ansehen.
Du kannst ggf. ein Issue erstellen: https://github.com/ntruchsess/fhem-mirror/issues?q=is%3Aopen+is%3Aissue
Oder Du überträgst die Werte als normale Reading (analog Termperatur etc.)
Ok. Das würde das Problem zumindest erklären. Weißt du zufällig,ob Norbert hier noch mitliest?
Was schreibt man denn in so ein Issue rein? Habe sowas noch nie gemacht. Kannst du das ggf. machen sonst schreibe ich Norbert einfach mal eine Nachricht.
Danke für deine Hilfe!
keine Ahnung, ob er hier noch mitliesst. Schreibe ihm einfach eine Nachricht. Ein Issue ist ja auch nichts anderes, als eine Fehlerbeschreibung.
Das Problem hat sich aufgelöst. Es lag daran, dass ich zum Testen einen Arduino Nano genutzt habe. Heute kam der erste Arduino Pro Mini an und mit diesem werden die Batteriewerte perfekt übertragen. :)
OK, das verstehe ich zwar nicht, aber wenn das jetzt funktioniert... :)
Ich kann es mir auch nicht erklären, aber im Log tauchen nun auch korrekte Meldungen auf, die das Modul offenbar verwertet:
2015.03.23 11:56:40 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'read: 100-100-0 s=255,c=3,t=0,pt=1,l=1:82'
2015.03.23 11:56:40 5: MYSENSORS gateway MySensors: read: 100-100-0 s=255,c=3,t=0,pt=1,l=1:82
2015.03.23 11:56:40 5: MYSENSORS Read: Rx: fr=100 ci=255 c=003(C_INTERNAL ) st=000(I_BATTERY_LEVEL ) ack=0 '82'
Langsam verzweifle ich mit der Vergabe der Node IDs.
Bis vor paar Minuten hatte ich wenigstens einen funktionierenden Sensor (Temp,Hum,Pres) mit Übermittlung des Batteriestandes (Node ID 102). Da ich mir nicht erklären könnte wieso der Batteriestand meines Motion/Light Sensor (Node ID 0) von Fhem nicht erkannt wird habe ich einfach mal den Motion/Light vom Hexenmeister mit meiner Batterie-Ergänzung aufgespielt.
Der Sensor wurde von Fhem erkannt, aber wiederum mit der ID 0 angelegt. Der Batteriestand fehlte. Daher habe ich meinen funktionieren Sensors (ID 102) ebenfalls mit dem gleichen Sketch bespielt. Die angeschlossenen Sensoren passen zwar nicht, aber wenigstens die Batteriemessung hätte ja erkannt werden müssen. Interessanterweise wurde auch dieser Sensor mit der ID 0 angelegt und natürlich ohne Batteriestand...
Daraufhin habe ich beide Sensoren mit dem Standard Batterie-Sketch von der MySensors Website bespielt. Wiederrum werden bei Sensoren als ID 0 angelegt.
Ich gehe daher langsam davon aus, dass entweder mein Serial-Gateway spinnt oder die ID Vergabe an die Nodes im Fhem Modul nicht richtig funktioniert. Es kann ja nicht korrekt sein, dass mehrere Nodes die gleiche ID zuordnet bekommen.
Wenn ich dem Sensor eine feste ID gebe, in dem ich "gw.begin();" durch "gw.begin(NULL, 42);" 42 steht hier für die ID, wird der Sensor ohne Probleme mit der ID 42 angelegt und auch der Batteriestand wird als Reading angelegt.
Demnach muss doch ein Fehler bei der Vergabe der ID bestehen oder bin ich auf dem Holzweg?
Hallo Spezialtrick,
ich denke nicht das es am FHEM liegt, da ich gestern auch einen Sensor per "Auto-ID" in das FHEM eingepflegt hatte (sonst haben meine Sensoren auch "feste ID's").
Wichtig ist auch, wenn man verschiedene Sketche mit IDs ausprobiert, sollte man den EEPROM vorher löschen, da die Informationen bei Erstkontakt dort hinterlegt werden! Versuche das erst einmal, ob das funktioniert.
Also
1. "ClearEepromconfig" auf den Arduino spielen
2. 1x Reste drücken, damit er sicher einmal das Programm abarbeitet
3. dein Sketch wieder aufspielen
4. 1x Reset drücken
jetzt sollte es funktionieren.
Gruß fh555
Hallo fh555,
Vielen Dank für deine Antwort. Du hast Recht. Es liegt daran, dass ich das EEPROM nicht richtig gelöscht habe.
Ich habe statt dem "ClearEepromconfig" Sketch immer den "eeprom_clear" verwendet. -.-
Nun funktioniert es wie gewollt. :)
Hallo Spezialtrick,
freut mich, dass ich dir helfen konnte. ;D
Hallo,
kaspern nun schon ein paar Stunden am MySensors Projekt.
Habe ein serielles Gateway und einen Distance Sensor aufgebaut.
Nachdem ich nun hin und hergelesen habe, habe ich gerade meinen Distanz Sensor mit dem Seriellen Monitor der Arduinio Software getestet
send: 255-255-255-0 s=255,c=3,t=3,pt=0,l=0,st=fail:
Ping: 5 cm
req node id
send: 255-255-255-0 s=255,c=3,t=3,pt=0,l=0,st=fail:
Die Entfernung hab ich mehrfach geändert und es passt dann auch wohl.
Was ist mit dem Kondenstor der zwischen VCC und GND empholen wird?
Leider hat der Ardunio für das Gateway irgendwie eine Macke.
Am Raspi angeschlossen
pi@raspberrypi ~ $ ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root root 13 May 3 16:03 usb-FTDI_FT232R_USB_UART_A96HTBN7-if00-port0 -> ../../ttyUSB0
pi@raspberrypi ~ $
soll doch wohl heissen das er ok ist.
Wenn ich den Baustein dann solo oder mit Funkbauteil am PC anschließe kommt im Geräte Manager
Die Treiber für dieses Gerät wurden nicht installiert. (Code 28)
Es sind keine kompatiblen Treiber für dieses Gerät vorhanden.
dementsprechend komme ich im Ardunio seriell Monitor nicht ran.
was tun, neuen flashen ( hab ja noch 4)
oder kann man den retten?
welchen Sketch wenn ich ihn über usb am raspi anschließe
den von der mysensor Seite
SerialGateway
wie das geht weiß ich ja jetzt
:P
so habe noch einen anderen neue ausprobiert die selbe Fehlermeldung
dann noch einen von einem anderen Lieferanten
der funktioniert
also SerialGateway.ino von MySensors neu geflasht
und dann mit dem Serial Monitor, nun weiß ich was das ist...
überprüft
gibt das hier aus ( leider nicht kopiert also per Hand - sollte richtig sein?!)
0;0;3;0;14;Gateway startup complete.
das hier zeigt fhem:
DEF
/dev/ttyAMA0@115200
DeviceName
/dev/ttyAMA0@115200
FD
4
NAME
gateway
NOTIFYDEV
global
NR
91
NTFY_ORDER
50-gateway
PARTIAL
���� ~�����
STATE
connected
TYPE
MYSENSORS
ack
0
inclusion-mode
1
outstandingAck
0
nur der Sensor Distanz taucht nicht auf grrrrrr
ZitatNachdem ich nun hin und hergelesen habe, habe ich gerade meinen Distanz Sensor mit dem Seriellen Monitor der Arduinio Software getestet
send: 255-255-255-0 s=255,c=3,t=3,pt=0,l=0,st=fail:
Ping: 5 cm
req node id
send: 255-255-255-0 s=255,c=3,t=3,pt=0,l=0,st=fail:
Der Sensor frag nach einer neue ID und bekommt sie nicht. Du musst den Gateway in inclusion mode versetzen.
Zitat
Was ist mit dem Kondenstor der zwischen VCC und GND empholen wird?
Bei einer stabilen Versorgung brauchst Du den nicht.
Mit den Treiberproblemen kann ich leider nichts anfangen. Es gab zwar schon mal Probleme mit Windows-Treibern und gefälschten FTDI-Chips, da haben die Originaltreiber den Chip (ducht setzen von VID und PID auf 0) lahmgelegt. Aber dann würde dieser Chip auch nicht mehr unter Linux funktionieren.
Hallo
thanks,
hatte das schon mal gemacht, aber mit dem vorherigen ardunio, ob ich das bei dem neune schon gemacht hatte ?
das kommt nun
2015.05.03 19:14:22 5: MYSENSORS/RAW: /���� ~�����
2015.05.03 20:53:40 5: MYSENSORS send: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=005(I_INCLUSION_MODE) ack=0 '1'
2015.05.03 20:53:40 5: SW: 303b303b333b303b353b310a
2015.05.03 20:53:40 5: MYSENSORS/RAW: ���� ~�����/�� >|����
2015.05.03 20:55:01 5: MYSENSORS send: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=005(I_INCLUSION_MODE) ack=0 '1'
2015.05.03 20:55:01 5: SW: 303b303b333b303b353b310a
2015.05.03 20:55:01 5: MYSENSORS/RAW: ���� ~������� >|����/�� ~�����
2015.05.03 20:55:13 5: MYSENSORS send: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=005(I_INCLUSION_MODE) ack=0 '1'
2015.05.03 20:55:13 5: SW: 303b303b333b303b353b310a
2015.05.03 20:55:13 5: MYSENSORS/RAW: ���� ~������� >|������ ~�����/�� ~�����
2015.05.03 20:55:54 5: MYSENSORS send: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=005(I_INCLUSION_MODE) ack=0 '1'
2015.05.03 20:55:54 5: SW: 303b303b333b303b353b310a
das hier war am Ardunio Serial monitor, da war das gateway nicht im Spiel
Nachdem ich nun hin und hergelesen habe, habe ich gerade meinen Distanz Sensor mit dem Seriellen Monitor der Arduinio Software getestet
send: 255-255-255-0 s=255,c=3,t=3,pt=0,l=0,st=fail:
Ping: 5 cm
req node id
send: 255-255-255-0 s=255,c=3,t=3,pt=0,l=0,st=fail:
Zitat von: Franz Tenbrock am 03 Mai 2015, 20:58:11
das kommt nun
2015.05.03 19:14:22 5: MYSENSORS/RAW: /���� ~�����
Das sieht irgendwie nach einer falschen Baudrate-Einstellung...
Zitat von: Franz Tenbrock am 03 Mai 2015, 21:19:57
das hier war am Ardunio Serial monitor, da war das gateway nicht im Spiel
Nachdem ich nun hin und hergelesen habe, habe ich gerade meinen Distanz Sensor mit dem Seriellen Monitor der Arduinio Software getestet
send: 255-255-255-0 s=255,c=3,t=3,pt=0,l=0,st=fail:
Ping: 5 cm
req node id
send: 255-255-255-0 s=255,c=3,t=3,pt=0,l=0,st=fail:
Das ist schon klar. Dieser Sensor hat keine ID und muss erstmal eine bekommen.
das ist der Sketch en ich geflasht habe
#include <SPI.h>
#include <MySensor.h>
#include <NewPing.h>
#define CHILD_ID 1
#define TRIGGER_PIN 6 // Arduino pin tied to trigger pin on the ultrasonic sensor.
#define ECHO_PIN 5 // Arduino pin tied to echo pin on the ultrasonic sensor.
#define MAX_DISTANCE 300 // Maximum distance we want to ping for (in centimeters). Maximum sensor distance is rated at 400-500cm.
unsigned long SLEEP_TIME = 5000; // Sleep time between reads (in milliseconds)
MySensor gw;
NewPing sonar(TRIGGER_PIN, ECHO_PIN, MAX_DISTANCE); // NewPing setup of pins and maximum distance.
MyMessage msg(CHILD_ID, V_DISTANCE);
int lastDist;
boolean metric = true;
void setup()
{
gw.begin();
// Send the sketch version information to the gateway and Controller
gw.sendSketchInfo("Distance Sensor", "1.0");
// Register all sensors to gw (they will be created as child devices)
gw.present(CHILD_ID, S_DISTANCE);
boolean metric = gw.getConfig().isMetric;
}
void loop()
{
int dist = metric?sonar.ping_cm():sonar.ping_in();
Serial.print("Ping: ");
Serial.print(dist); // Convert ping time to distance in cm and print result (0 = outside set distance range)
Serial.println(metric?" cm":" in");
if (dist != lastDist) {
gw.send(msg.set(dist));
lastDist = dist;
}
gw.sleep(SLEEP_TIME);
}
#define CHILD_ID 1
ist das die Zeile die auskommentiert werden muss also so:
define CHILD_ID 1
?
hab bisher kaum mit solchem code zu tun gehabt, daher die Frage
muss da sonst noch was an # gelöscht werden?
#define CHILD_ID 1
#define TRIGGER_PIN 6 // Arduino pin tied to trigger pin on the ultrasonic sensor.
#define ECHO_PIN 5 // Arduino pin tied to echo pin on the ultrasonic sensor.
#define MAX_DISTANCE 300 // Maximum distance we want to ping for (in centimeters). Maximum sensor distance is rated at
Kann man unter Umständen die Zeit in der er sich meldet ändern.
gw.sleep(SLEEP_TIME);
Soll in eine Zisterne , reicht da 1x in der Stunde !
Das Video zum Gateway war ja super ausführlich...
Schreibe dann mal das Ganze Projekt in einem Doku zusammen , halt für andere Anfänger
#define CHILD_ID1 ist vollkommen richtig.
Bei Arduino wird mit // auskommentiert.
Was zeigt dein Gateway in Fhem unter dem State Connection an?
Mit #-Zeichen fangen Preprocessor-Anweisungen in C an. Es wird Dir helfen, zumindest die Grundlagen der C-Sprache anzusehen. ;)
Zitat von: Franz Tenbrock am 04 Mai 2015, 07:42:12
Soll in eine Zisterne , reicht da 1x in der Stunde !
Die SleepTime des Sensors wird im Sketch nachfolgen definiert:
unsigned long SLEEP_TIME = 5000; // Sleep time between reads (in milliseconds)
Wenn du die 5000 in 3600000 änderst, wacht der Sensor nur Stündlich auf.
Perl FHEM und jetzt noch C
grrrrrrrr
Spass beiseite,
Danke für eure Unterstützung, werde es heute mittag , das Ergebniss so als nachtisch servieren.
so jetzt läufts
hab einfach das Gateway falsch definiert ...
Die Infos liegen irgendwie weit verstreut.
Das hier irgendwie gefunden und damit hats dann endlich geklappt
http://forum.fhem.de/index.php/topic,28198.msg210752.html#msg210752
Commandref meist für mich einfach zu wenig Infos, mir fehlt da einfach Background wissen....
define gateway MYSENSORS /dev/ttyUSB0@115200
Habe also alles was ich in der cfg hatte gelöscht und von vorne angefangen, natürlich nach reboot....
mit dieserDefinition hat er dann auch recht schnell den Sensor entdeckt.
Werde das nun im pdf neu schreiben und dann klappts hoffentlich.
Werde nun auch die 2 Ardunios testen die am windows pc nicht mehr gehen...
werde bereichten....
nun hab ich 2 funktionierende Sensoren 8) :D 8)
Warum ich das gateway falsch definiert hatte ?????
Das Dokument steht zur freien Verfügung und darf auch geändert werden., ich hoffe es hilft dem einen oder anderen
15 mal geladen,
und so verständlich ??
Ich hoffe man kann es gebrauchen...
hoffentlich keine Fehler
Hallo Franz,
für das internal STATE kannst Du z.B. das attribut "stateFormat distance1 cm" setzen.
Wird aber dann (bei mir jedenfalls) immer nur aktualisiert, wenn die Website refreshed wird... (das reading "distance1" wird natürlich schon sofort aktualisiert)
VG
Karl
Hallo
warte nun erst mal auf einen wasserdichten/feuchtigkeitsgeeigneten Sensor bevor ich da weitermache.
Als nächstes möchte ich erst einmal 4 Taster haben die den Schaltzustand einer lampe die ich von FHEM schon steuern kann auf einem Testboard zum laufen bringen. Dazu muss ich erst mal viel viel lesen so wie ich gerade sehe grrrrr
Auf der mysensors Seite sind zwar reichlich Beispiele aber nicht so das man als absoluter Anfänger da schnell reinkommt.
FHEM hab ich auch schrittweise erlernt, so dass ich zuhause schon eine Menge steuern kann...
Da gibt es das Beispiel hier durch das ich mich gerade durchbeisse , um es zu verstehen....
// Example sketch showing how to control physical relays.
// This example will remember relay state even after power failure.
#include <MySensor.h>
#include <SPI.h>
#define RELAY_1 3 // Arduino Digital I/O pin number for first relay (second on pin+1 etc)
#define NUMBER_OF_RELAYS 1 // Total number of attached relays
#define RELAY_ON 1 // GPIO value to write to turn on attached relay
#define RELAY_OFF 0 // GPIO value to write to turn off attached relay
MySensor gw;
void setup()
{
// Initialize library and add callback for incoming messages
gw.begin(incomingMessage, AUTO, true);
// Send the sketch version information to the gateway and Controller
gw.sendSketchInfo("Relay", "1.0");
// Fetch relay status
for (int sensor=1, pin=RELAY_1; sensor<=NUMBER_OF_RELAYS;sensor++, pin++) {
// Register all sensors to gw (they will be created as child devices)
gw.present(sensor, S_LIGHT);
// Then set relay pins in output mode
pinMode(pin, OUTPUT);
// Set relay to last known state (using eeprom storage)
digitalWrite(pin, gw.loadState(sensor)?RELAY_ON:RELAY_OFF);
}
}
void loop()
{
// Alway process incoming messages whenever possible
gw.process();
}
void incomingMessage(const MyMessage &message) {
// We only expect one type of message from controller. But we better check anyway.
if (message.type==V_LIGHT) {
// Change relay state
digitalWrite(message.sensor-1+RELAY_1, message.getBool()?RELAY_ON:RELAY_OFF);
// Store state in eeprom
gw.saveState(message.sensor, message.getBool());
// Write some debug info
Serial.print("Incoming change for sensor:");
Serial.print(message.sensor);
Serial.print(", New status: ");
Serial.println(message.getBool());
}
}
Es wäre halt schön und deutlich einfacher wenn die Kommentarfunktion die ja da ist ausführlciher benutzt werden würde :-(
#include <MySensor.h>
#include <SPI.h>
include ist klar, soll berücksichtigt werden, aber ein kurzer Hinweis was eigentlich mysensor.h ist wäre schon hilfreich...
klar irgendwo steht es, man kann auch in die Datei reinschauen, aber das dauert alles ewig....
#define RELAY_1 3 // Arduino Digital I/O pin number for first relay (second on pin+1 etc)
das dann das 2. Relais so sein muss
#define RELAY_2 4 // Arduino Digital I/O pin number for second relay
#define NUMBER_OF_RELAYS 2 // Total number of attached relays
#define RELAY_ON 1 // GPIO value to write to turn on attached relay was da passiert ???
#define RELAY_OFF 0 // GPIO value to write to turn off attached relay
Ich denke man versteht was ich sagen will, der Schluß von 1 bis 3 Relais wäre nachvollziehbar wenn eben 2.Relais mit aufgenommen wäre. Es nervt mich eigentlich immer wieder fragen zu müssen, eigentlich müsste ich mir fertige Schalter kaufen wenn es ums Geld ginge, aber ich würde es lieber lernen, aber die Zeit ist halt begrenzt
Ich schreibe ja auch immer alles auf, Schritt für Schritt damit ich es selber auch noch nach Monaten nachvollziehen kann..
wenn ich da weiter durch den code gehe
// Initialize library and add callback for incoming messages
gw.begin(incomingMessage, AUTO, true);
// Send the sketch version information to the gateway and Controller
gw.sendSketchInfo("Relay", "1.0");
Initialisierung des Sensors und Übermittlung das es sich um ein Relais mit Version 1.0 handelt. Da könnte man also beliebig was reinschreiben, nur Syntax halt beaachten?!
// Fetch relay status
for (int sensor=1, pin=RELAY_1; sensor<=NUMBER_OF_RELAYS;sensor++, pin++) {
also den aktuellen Zustand erst einmal abholen
int sensor=1 ????
pin=Relay_1 wäre dann ja wohl 3
pin=Relay_2 wäre dann ja wohl 4
sensor<=NUMBER_OF_RELAYS;sensor++, pin++) { ????????
wie das nun für 2 Relais ausschauen muss ??? wenn nun in diesem Beispiel 2 Relais wären , könnte man problemlos auf das 3. und 4 schließen
// Register all sensors to gw (they will be created as child devices)
gw.present(sensor, S_LIGHT);
Hier wird dann wohl alles erst einmal im Gateway registriert, wer ist was?
was bedeutet nun wieder child devices??
Einfaches Beispiel trotzdem gleich zig Fragen...halt wie bei FHEM am Anfang auch....
Aber ein Trost..
Es sind ja einige sofort lauffähige Beispiele dabei, und das kann ich ja nun mit links...
so nun doch was gefunden, man muss halt nur lang genug suchen und es funktioniert...sowohl auf dem ardunio als auch in fhem :-)
Auch wenn ich Anfänger und alles andere als ein Programmierer bin. Wiki Artikel wäre doch wichtig, würde es auch versuchen den zu schreiben,
hab da schon mal was hochgeladen. Zisternen mit Ultraschallsensor
aber nur wenn es Unterstützung gibt, also wiki lesen und Fehler melden....
das suchen nach Infos ist einfach fürchterlich mühsam
war im Februar schon mal Thema.. (Link hier)
http://forum.fhem.de/index.php/topic,31663.msg263517.html#msg263517
Antw:MySensor Relay anbinden « Antwort #12 am: 12 Januar 2015, 14:53:55 »
werde mich damit nun mal beschäftigen und dann heute abend dann was dazu schreiben..
// Example sketch f�r a "light switch" where you can control light or something
// else from both vera and a local physical button (connected between digital
// pin 3 and GND).
// This node also works as a repeader for other nodes
#include <MySensor.h>
#include <SPI.h>
#include <Bounce2.h>
#define RELAY_PIN1 3 // Arduino Digital I/O pin number for relay
#define RELAY_PIN2 4 // Arduino Digital I/O pin number for relay
#define RELAY_PIN3 5 // Arduino Digital I/O pin number for relay
#define BUTTON_PIN1 6 // Arduino Digital I/O pin number for button
#define BUTTON_PIN2 7 // Arduino Digital I/O pin number for button
#define BUTTON_PIN3 8 // Arduino Digital I/O pin number for button
#define CHILD_ID 1 // Id of the sensor child
#define RELAY_ON 0
#define RELAY_OFF 1
Bounce debouncer1 = Bounce();
Bounce debouncer2 = Bounce();
Bounce debouncer3 = Bounce();
int oldValue1=0;
int oldValue2=0;
int oldValue3=0;
bool state1;
bool state2;
bool state3;
MySensor gw;
MyMessage msg1(1,V_LIGHT);
MyMessage msg2(2,V_LIGHT);
MyMessage msg3(3,V_LIGHT);
void setup()
{
gw.begin(incomingMessage, AUTO, true);
// Send the sketch version information to the gateway and Controller
gw.sendSketchInfo("Relay & Button", "1.0");
// Setup the button
pinMode(BUTTON_PIN1,INPUT);
pinMode(BUTTON_PIN2,INPUT);
pinMode(BUTTON_PIN3,INPUT);
// Activate internal pull-up
digitalWrite(BUTTON_PIN1,HIGH);
digitalWrite(BUTTON_PIN2,HIGH);
digitalWrite(BUTTON_PIN3,HIGH);
// After setting up the button, setup debouncer
debouncer1.attach(BUTTON_PIN1);
debouncer2.attach(BUTTON_PIN2);
debouncer3.attach(BUTTON_PIN3);
debouncer1.interval(5);
debouncer2.interval(5);
debouncer3.interval(5);
// Register all sensors to gw (they will be created as child devices)
gw.present(1, S_LIGHT);
gw.present(2, S_LIGHT);
gw.present(3, S_LIGHT);
// Make sure relays are off when starting up
digitalWrite(RELAY_PIN1, RELAY_OFF);
digitalWrite(RELAY_PIN2, RELAY_OFF);
digitalWrite(RELAY_PIN3, RELAY_OFF);
// Then set relay pins in output mode
pinMode(RELAY_PIN1, OUTPUT);
pinMode(RELAY_PIN2, OUTPUT);
pinMode(RELAY_PIN3, OUTPUT);
// Set relay to last known state (using eeprom storage)
state1 = gw.loadState(1);
digitalWrite(RELAY_PIN1, state1?RELAY_ON:RELAY_OFF);
state2 = gw.loadState(2);
digitalWrite(RELAY_PIN2, state2?RELAY_ON:RELAY_OFF);
state3 = gw.loadState(3);
digitalWrite(RELAY_PIN3, state3?RELAY_ON:RELAY_OFF);
}
/*
* Example on how to asynchronously check for new messages from gw
*/
void loop()
{
gw.process();
debouncer1.update();
debouncer2.update();
debouncer3.update();
// Get the update value
int value1 = debouncer1.read();
if (value1 != oldValue1 && value1==0) {
gw.send(msg1.set(state1?false:true), true); // Send new state and request ack back
}
oldValue1 = value1;
// Get the update value
int value2 = debouncer2.read();
if (value2 != oldValue2 && value2==0) {
gw.send(msg2.set(state2?false:true), true); // Send new state and request ack back
}
oldValue2 = value2;
// Get the update value
int value3 = debouncer3.read();
if (value3 != oldValue3 && value3==0) {
gw.send(msg3.set(state3?false:true), true); // Send new state and request ack back
}
oldValue3 = value3;
}
void incomingMessage(const MyMessage &message) {
// We only expect one type of message from controller. But we better check anyway.
if (message.isAck()) {
Serial.println("This is an ack from gateway");
}
if (message.type == V_LIGHT) {
// Change relay state
if(message.sensor==1){
digitalWrite(RELAY_PIN1, message.getBool()?RELAY_ON:RELAY_OFF);
state1=message.getBool();
}
if(message.sensor==2){
digitalWrite(RELAY_PIN2, message.getBool()?RELAY_ON:RELAY_OFF);
state2=message.getBool();
}
if(message.sensor==3){
digitalWrite(RELAY_PIN3, message.getBool()?RELAY_ON:RELAY_OFF);
state3=message.getBool();
}
// Store state in eeprom
gw.saveState(message.sensor, message.getBool());
// Write some debug info
Serial.print("Incoming change for sensor:");
Serial.print(message.sensor);
Serial.print(", New status: ");
Serial.println(message.getBool());
}
}
Ich habe das Gefühl, das der Repeater Sketch bei MySensors nicht funktioniert. Ich wollte den Repeater als "man in the middle" betreiben.
wenn ich ihn am USB hänge, sieht alles ok aus.
Zitatsend: 108-108-0-0 s=255,c=0,t=18,pt=0,l=5,st=ok:1.4.1
send: 108-108-0-0 s=255,c=3,t=6,pt=1,l=1,st=ok:0
read: 0-0-108 s=255,c=3,t=6,pt=0,l=1:M
send: 108-108-0-0 s=255,c=3,t=11,pt=0,l=13,st=ok:Repeater Node
send: 108-108-0-0 s=255,c=3,t=12,pt=0,l=3,st=ok:1.0
Muss man an den Nodes noch was einstellen, das er aktiviert wird? Ich glaube die Nodes umgehen den Repeater.
Sieht man irgendwo in Fhem-Log, das das Signal von einem Sensor über den Repeater gegangen ist?
LG
/robin
Hat jemand schon eine Möglichkeit gefunden das Ethernet-Gateway auf dem ESP8266 zu betreiben? Dann könnte man das einfach da hinlegen wo man will ohne auf eine Ethernet- oder USB-Verbindung angewiesen zu sein.
Viele Grüße,
Markus
Zitat von: fh168 am 03 Juli 2015, 19:44:38
Ich habe das Gefühl, das der Repeater Sketch bei MySensors nicht funktioniert. Ich wollte den Repeater als "man in the middle" betreiben.
wenn ich ihn am USB hänge, sieht alles ok aus.
Muss man an den Nodes noch was einstellen, das er aktiviert wird? Ich glaube die Nodes umgehen den Repeater.
Sieht man irgendwo in Fhem-Log, das das Signal von einem Sensor über den Repeater gegangen ist?
LG
/robin
Der Node muss erst 3 mal ohne Erfolg ein Paket verschicken um dann eine neue Route festzulegen und den Repeater zu nutzen. Hab ich letztens erst im MySensors Forum gelesen.
ZitatThe first time a new sensor boots up, it will determine the path to the gateway by sending out a special Help-me-find-my-way-home-message. The repeater-sensor nodes and gateway listen for these messages and will respond to a sensor's plea-for-help-message. Their reply will inform the sensor how far they are from the gateway so the newly born sensor can determine the shortest path to the gateway, be it directly to the gateway or through a repeater-sensor node which is the closest to the gateway. If the sensor node later loses contact with the gateway or a repeater-sensor node, it will automatically repeat this procedure to determine the best path to the gateway - a sensor node considers contact with the gateway to be lost if it fails to send 3 consecutive messages.
Danke Gloob, probiere ich aus.
LG
/robin
Kann man das Modul um die neuen Variablen der MySensor Version 1.5 erweitern?
Ich hätte Interesse an einem RGB Wert um Lampen anzusteuern.
Zitat von: gloob am 13 August 2015, 14:26:16
Kann man das Modul um die neuen Variablen der MySensor Version 1.5 erweitern?
Ich hätte Interesse an einem RGB Wert um Lampen anzusteuern.
Der Maintainer des Moduls ist ntruchsess. Schreibe ihm doch vielleicht eine PN mit dem Link zu deinem Post?
So jetzt benötige ich auch die neuen Variablen. Wollte den Air Quality Sensor benutzen.
moin,
ich muss auch mal eben eine frage in den Raum werfen. Ich habe hier auch Mysensors in Gebrauch, klappt auch alles soweit ganz gut wenn es um das Senden vom Sensor zu FHEM geht. Die andere Richtung klappt auch, wenn ich beim Versuchsaufbau die Verbindung vom Atmel zum Funkboard anfasse. Dann kommen Daten an und werden auch mit OK bestätigt.
Hier liegt irgendwie ein Hardwaretchnisches Problem vor, ich bin aber noch nicht dahinter gestiegen, welches. Diese Phänomen scheint bei allen drei Aufbauten (verschiedenste Aufbauten) zu bestehen.
Scheinbar bilden sich irgendwelche Kapazitäten mit den Fingern aus die dafür sorgen das es klappt.
Ganz eigenwürdige Geschichte...hat dies Phänomen irgendjemand bei sich beobachtet?
Konfiguration ist übrigens der "grosse" Transmitter mit Antenne am Bananapi (SerialGateway) und die normalen Sensoren / Funkmodule als Nodes.
Die Programmierung ist richtig soweit, es funzt ja mit ein wenig Hilfe...
Irgendwelche Ideen?
Grüße
Marie
Hallo Gemeinde,
hat jemand schon das ESP8266 Gateway für MySensors nachgebaut?
http://forum.mysensors.org/topic/1870/esp8266-wifi-gateway-port-for-mysensors
LG
/robin
Mist, wieder eine neue Baustelle ;)
Ich hab das mal selbst versucht auf dem ESP zum laufen zu bekommen, bin gespannt was dort anders gemacht wurde :)
Zitat von: fh168 am 06 September 2015, 18:36:40
hat jemand schon das ESP8266 Gateway für MySensors nachgebaut?
http://forum.mysensors.org/topic/1870/esp8266-wifi-gateway-port-for-mysensors
scheint zu funktionieren ;)
muss noch etwas länger testen.
(http://forum.fhem.de/index.php?action=dlattach;topic=26807.0;attach=36993;image)
(http://forum.fhem.de/index.php?action=dlattach;topic=26807.0;attach=36991;image)
Edit: Die LEDs habe ich erstmal hingemalt, wird aber so nur gehen, wenn man alle seriellen Ausgaben lahmlegt. Die GPIOs hier sind leider knapp :( Evtl. lassen sich noch GPIO0 und GPIO2 verwenden.
Ich habe mit ntruchsess Kontakt aufgenommen und mit seiner Zustimmung angefangen, dass Modul auf MySensor v 1.5 upzudaten:
https://github.com/Kolbi/fhem-mirror/blob/patch-1/fhem/FHEM/10_MYSENSORS_DEVICE.pm
Leider derzeit noch ungetestet! Feedback wäre, super.
Hallo,
nur mal ne Frage. Für was ein WLAN Gateway mit dem nRF24L01?
Beide Senden auf 2,4GHz. Je nach Ausführung der Module bekomme ich eine ähnliche Reichweite. Warum dann kein LAN Gateway direkt an den Router? Das Gateway benötigt eine Stromversorgung, Batterie wird da wohl nicht lange reichen. Und wenn die Reichweite des nRF24L01 nicht reicht, kann ich doch anstelle des Gateways ein Mysensor Repeater hinstellen.
Das soll jetzt keine Kritik an der Entwicklung sein. Das sich Leute solche Projekte ausdenken, zusammenbauen und zur Funktion und dann Veröffentlichen finde ich super. Da habe ich vollen Respekt. Ich überlege mir bei neuen Vorstellungen von Projekten immer, ob ich das auch verwenden könnte. Und hier finde ich eben keinen Einsatzzweck. Daher die Frage. Den ich glaube kaum, das es viele Nachbauten gibt, um einen LAN-Port am Router zu sparen. Mit dem RFM69 würde das dann schon anders aussehen.
Viele Grüße
Achim
Naja, WLAN Gateway hat schon Vorteile.
Ich verwende derzeit notgedrungen zwei Transmitter: einen mit USB und einen LAN. Würde eigentlich eins auch reichen, der muss dann aber in die Mitte zw. den am weitesten entfernten Sensoren. Da habe ich aber kein Ethernet. Klar, geht auch mit einem Repeater, aber wenn ich mit nur einem WLAN Gateway auskommen kann... und Strom brauchen sie beide ;)
Ein weiterer Pluspunkt ist die Tatsache, dass WLAN Gateway bis zu 5 Verbindungen gleichzeitig zulässt. Damit kann ich parallel (mit MYSController) von meinem Laptop aus den Verkehr monitoren (mit einem speziellen Bootloader soll sich auch Firmware flashen). LAN-Gateway unterstützt max. eine Verbindung.
Interessanterweise ist WLAN Gateway sogar etwas billiger (ESP8266 + nRF24L01+ => ca. 3,5 Euro) als ein LAN Gateway (Arduino + nRF24L01+ + LAN-Chip => 5-6 Euro). ;)
Hallo Alexander,
vielen Dank für die Antwort. Der Punkt mit dem parallel monitoren klingt interessant. Schreibe ich mir mal auf meine lange "könnte ich auch noch machen" Liste.
Viele Grüße
Achim
Hallo Hexenmeister,
wie immer vorbildliche Arbeit, das werde ich am Wochenende mal nachbauen. Vielen Dank.
Eine technische Frage habe ich noch:
Meine Kollege und ich aus dem Forum hier fragen sich, wie es sichergestellt ist, das die Daten vom WLAN in Fhem richtig auflaufen? Da müsste ja eine ständiger Datentransfer sein? Was passiert, wenn der Datenstrom abbricht? Wird das Paket dann nochmal gestartet?
LG
/robin
Hi Robin,
ich habe mich mit dem Sketch noch nicht wirklich beschäftigt, daher, was ich jetzt schreibe ist 'glauben' und nicht 'wissen', ich bin mir aber recht sicher, dass da keine Vorkehrungen gegen Datenverlust vorhanden sind.
Ständiger Datentransfer ist dennoch relativ. Eine Verbindung muss stehen, die Daten fließen jedoch nur, wenn es was zu melden gibt. Die Übertragung ist natürlich gesichert (TCP) daher werden fehlerhafte Pakete erneut gesendet. Wenn die Verbindung jedoch ganz abbricht, dann kommt nichts mehr.
Das ist bei einem LAN-Gateway aber auch nicht anders. Da ich dort auch mit Abbrüchen zu kämpfen habe, habe ich in FHEM einen ständigen reconnect eingebaut (mit AT, jede Minute). Nicht schön, tut aber.
Ich würde gerne das auf MQTT umbauen, das dürfte deutlich sicherer sein. Mir fehlt aber, wie immer, an Zeit :(
Zitat von: Hauswart am 09 September 2015, 11:11:40
Ich habe mit ntruchsess Kontakt aufgenommen und mit seiner Zustimmung angefangen, dass Modul auf MySensor v 1.5 upzudaten:
https://github.com/Kolbi/fhem-mirror/blob/patch-1/fhem/FHEM/10_MYSENSORS_DEVICE.pm
Leider derzeit noch ungetestet! Feedback wäre, super.
Hallo Hauswart,
Ich habe heute versucht deine Änderungen bei mir einzufügen, jedoch bekomme ich viele Fehler beim Start von FHEM.
Hast du eine Idee woran das liegen könnte?
2015.09.11 08:46:30 1: starting in console mode
2015.09.11 08:46:30 1: Including fhem.cfg
2015.09.11 08:46:30 3: telnetPort: port 7072 opened
2015.09.11 08:46:32 3: WEB: port 8083 opened
2015.09.11 08:46:32 3: WEBphone: port 8084 opened
2015.09.11 08:46:32 3: WEBtablet: port 8085 opened
2015.09.11 08:46:32 2: eventTypes: loaded 0 events from ./log/eventTypes.txt
2015.09.11 08:46:32 1: reload: Error:Modul 10_MYSENSORS_DEVICE deactivated:
Bareword "V_AMRED" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_AMRED" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_AMRED" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_PERCENTAGE" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_PERCENTAGE" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_ID" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_SETPOINT_HEAT" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_FLOW_STATE" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_UNIT_PREFIX" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_LEVEL" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_LEVEL" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_UNIT_PREFIX" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_LEVEL" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_UNIT_PREFIX" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_RGB" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_RGB" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_RGBW" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_RGBW" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_RGB" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_RGB" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_SETPOINT_HEAT" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_SETPOINT_COLD" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_FLOW_STATE" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_FLOW_MODE" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_SPEED" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_LEVEL" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_LEVEL" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_LEVEL" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
2015.09.11 08:46:32 0: Bareword "V_AMRED" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_AMRED" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_AMRED" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_PERCENTAGE" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_PERCENTAGE" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_ID" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_SETPOINT_HEAT" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_FLOW_STATE" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_UNIT_PREFIX" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_LEVEL" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_LEVEL" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_UNIT_PREFIX" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_LEVEL" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_UNIT_PREFIX" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_RGB" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_RGB" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_RGBW" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_RGBW" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_RGB" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_RGB" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_SETPOINT_HEAT" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_SETPOINT_COLD" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_FLOW_STATE" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_FLOW_MODE" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_SPEED" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_LEVEL" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_LEVEL" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_LEVEL" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
2015.09.11 08:46:32 1: Including ./log/fhem.save
2015.09.11 08:46:32 1: configfile: Cannot load module MYSENSORS_DEVICE
2015.09.11 08:46:32 3: initialUsbCheck return value: This command is not yet supported on windows
2015.09.11 08:46:32 2: Error messages while initializing FHEM: configfile: Cannot load module MYSENSORS_DEVICE
2015.09.11 08:46:32 0: Featurelevel: 5.6
2015.09.11 08:46:32 0: Server started with 9 defined entities (version $Id: fhem.pl 9163 2015-08-30 07:57:51Z rudolfkoenig $, os MSWin32, user PCE Pilot, pid 3620)
Habe den Fehler hoffentlich korrigiert :) Bitte nochmal neu herunterladen und testen.
PS: https://raw.githubusercontent.com/Kolbi/fhem-mirror/patch-1/fhem/FHEM/10_MYSENSORS_DEVICE.pm
Hast du etwas verändert? Weil ich bekomme noch den gleichen Fehler. An was kann der Fehler liegen?
Zitat von: hexenmeister am 11 September 2015, 10:40:03
Hi Robin,
ich habe mich mit dem Sketch noch nicht wirklich beschäftigt, daher, was ich jetzt schreibe ist 'glauben' und nicht 'wissen', ich bin mir aber recht sicher, dass da keine Vorkehrungen gegen Datenverlust vorhanden sind.
Ständiger Datentransfer ist dennoch relativ. Eine Verbindung muss stehen, die Daten fließen jedoch nur, wenn es was zu melden gibt. Die Übertragung ist natürlich gesichert (TCP) daher werden fehlerhafte Pakete erneut gesendet. Wenn die Verbindung jedoch ganz abbricht, dann kommt nichts mehr.
Das ist bei einem LAN-Gateway aber auch nicht anders. Da ich dort auch mit Abbrüchen zu kämpfen habe, habe ich in FHEM einen ständigen reconnect eingebaut (mit AT, jede Minute). Nicht schön, tut aber.
Ich würde gerne das auf MQTT umbauen, das dürfte deutlich sicherer sein. Mir fehlt aber, wie immer, an Zeit :(
Hallo Alex,
das Problem mit den Abbrüchen LAN Gateway habe ich auch. Welche Befehle startest Du mit Deinem at genau ?
Danke
Zitat von: gloob am 11 September 2015, 11:17:55
Hast du etwas verändert? Weil ich bekomme noch den gleichen Fehler. An was kann der Fehler liegen?
Ja, hatte ausversehen V_AMRED anstatt V_ARMED geschrieben. Hast du die neueste Version von Github heruntergeladen und ersetzt? Gleiche Fehlermeldungen?
Hallo,
Ich hab die Datei über deinen Link geladen und komplett im FHEM Ordner ersetzt.
Nur den Fehler mit V_AMRED gibt es nicht mehr. Alle anderen sind noch vorhanden. Scheinbar gibt es die Variablen nicht.
Zitat von: gloob am 11 September 2015, 13:01:14
Hallo,
Ich hab die Datei über deinen Link geladen und komplett im FHEM Ordner ersetzt. Einen Fehler mit V_AMRED scheint es auch nicht zu geben.
Kannst du mir bitte nochmal die aktuellen Fehlermeldung schicken?
2015.09.11 11:03:38 1: PERL WARNING: Terminating on signal SIGHUP(1)
2015.09.11 11:03:41 1: starting in console mode
2015.09.11 11:03:41 1: Including fhem.cfg
2015.09.11 11:03:41 3: telnetPort: port 7072 opened
2015.09.11 11:03:41 3: WEB: port 8083 opened
2015.09.11 11:03:41 3: WEBphone: port 8084 opened
2015.09.11 11:03:41 3: WEBtablet: port 8085 opened
2015.09.11 11:03:41 2: eventTypes: loaded 0 events from ./log/eventTypes.txt
2015.09.11 11:03:41 1: reload: Error:Modul 10_MYSENSORS_DEVICE deactivated:
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_PERCENTAGE" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_PERCENTAGE" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_ID" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_SETPOINT_HEAT" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_FLOW_STATE" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_UNIT_PREFIX" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_LEVEL" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_LEVEL" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_UNIT_PREFIX" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_LEVEL" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_UNIT_PREFIX" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_RGB" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_RGB" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_RGBW" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_RGBW" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_RGB" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_RGB" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_SETPOINT_HEAT" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_SETPOINT_COLD" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_FLOW_STATE" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_FLOW_MODE" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_SPEED" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_LEVEL" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_LEVEL" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_LEVEL" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
2015.09.11 11:03:41 0: Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_PERCENTAGE" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_PERCENTAGE" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_ID" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_SETPOINT_HEAT" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_FLOW_STATE" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_UNIT_PREFIX" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_LEVEL" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_LEVEL" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_UNIT_PREFIX" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_LEVEL" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_UNIT_PREFIX" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_RGB" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_RGB" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_RGBW" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_RGBW" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_RGB" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_RGB" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_SETPOINT_HEAT" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_SETPOINT_COLD" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_FLOW_STATE" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_FLOW_MODE" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_HVAC_SPEED" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_STATUS" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_LEVEL" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_LEVEL" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
Bareword "V_LEVEL" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 85, <$fh> line 38.
2015.09.11 11:03:41 1: Including ./log/fhem.save
2015.09.11 11:03:41 1: configfile: Cannot load module MYSENSORS_DEVICE
2015.09.11 11:03:41 3: initialUsbCheck return value: This command is not yet supported on windows
2015.09.11 11:03:41 2: Error messages while initializing FHEM: configfile: Cannot load module MYSENSORS_DEVICE
2015.09.11 11:03:41 0: Featurelevel: 5.6
2015.09.11 11:03:41 0: Server started with 9 defined entities (version $Id: fhem.pl 9163 2015-08-30 07:57:51Z rudolfkoenig $, os MSWin32, user PCE Pilot, pid 4004)
Startet FHEM bei dir ohne Probleme?
Kann es sein dass eine Anpassung in der C:\fhem-5.6\FHEM\lib\Device\MySensors\Constants.pm noch fehlt?
Hallo
Nachdem ich jetzt die Constants.pm wie folgt angepasst habe scheint es FAST zu gehen
Änderung:
package Device::MySensors::Constants;
use List::Util qw(first);
#-- Message types
use constant {
C_PRESENTATION => 0,
C_SET => 1,
C_REQ => 2,
C_INTERNAL => 3,
C_STREAM => 4,
};
use constant commands => qw( C_PRESENTATION C_SET C_REQ C_INTERNAL C_STREAM );
sub commandToStr($) {
(commands)[shift];
}
#-- Variable types
use constant {
V_TEMP => 0,
V_HUM => 1,
V_LIGHT => 2,
V_DIMMER => 3,
V_PRESSURE => 4,
V_FORECAST => 5,
V_RAIN => 6,
V_RAINRATE => 7,
V_WIND => 8,
V_GUST => 9,
V_DIRECTION => 10,
V_UV => 11,
V_WEIGHT => 12,
V_DISTANCE => 13,
V_IMPEDANCE => 14,
V_ARMED => 15,
V_TRIPPED => 16,
V_WATT => 17,
V_KWH => 18,
V_SCENE_ON => 19,
V_SCENE_OFF => 20,
V_HEATER => 21,
V_HEATER_SW => 22,
V_LIGHT_LEVEL => 23,
V_VAR1 => 24,
V_VAR2 => 25,
V_VAR3 => 26,
V_VAR4 => 27,
V_VAR5 => 28,
V_UP => 29,
V_DOWN => 30,
V_STOP => 31,
V_IR_SEND => 32,
V_IR_RECEIVE => 33,
V_FLOW => 34,
V_VOLUME => 35,
V_LOCK_STATUS => 36,
V_DUST_LEVEL => 37,
V_VOLTAGE => 38,
V_CURRENT => 39,
V_RGB => 40,
V_LEVEL => 41,
V_STATUS => 42,
V_RGBW => 43,
V_PERCENTAGE => 44,
V_ID => 45,
V_UNIT_PREFIX => 46,
V_HVAC_SETPOINT_HEAT => 47,
V_HVAC_SETPOINT_COLD => 48,
V_HVAC_FLOW_STATE => 49,
V_HVAC_FLOW_MODE => 50,
V_HVAC_SPEED => 51,
};
use constant variableTypes => qw{ V_TEMP V_HUM V_LIGHT V_DIMMER V_PRESSURE V_FORECAST V_RAIN
V_RAINRATE V_WIND V_GUST V_DIRECTION V_UV V_WEIGHT V_DISTANCE
V_IMPEDANCE V_ARMED V_TRIPPED V_WATT V_KWH V_SCENE_ON V_SCENE_OFF
V_HEATER V_HEATER_SW V_LIGHT_LEVEL V_VAR1 V_VAR2 V_VAR3 V_VAR4 V_VAR5
V_UP V_DOWN V_STOP V_IR_SEND V_IR_RECEIVE V_FLOW V_VOLUME V_LOCK_STATUS
V_DUST_LEVEL V_VOLTAGE V_CURRENT V_RGB V_LEVEL V_STATUS V_RGBW V_PERCENTAGE V_ID
V_UNIT_PREFIX V_HVAC_SETPOINT_HEAT V_HVAC_SETPOINT_COLD V_HVAC_FLOW_STATE V_HVAC_FLOW_MODE
V_HVAC_SPEED};
sub variableTypeToStr($) {
(variableTypes)[shift];
}
sub variableTypeToIdx($) {
my $var = shift;
return first { (variableTypes)[$_] eq $var } 0 .. scalar(variableTypes);
}
#-- Internal messages
use constant {
I_BATTERY_LEVEL => 0,
I_TIME => 1,
I_VERSION => 2,
I_ID_REQUEST => 3,
I_ID_RESPONSE => 4,
I_INCLUSION_MODE => 5,
I_CONFIG => 6,
I_PING => 7,
I_PING_ACK => 8,
I_LOG_MESSAGE => 9,
I_CHILDREN => 10,
I_SKETCH_NAME => 11,
I_SKETCH_VERSION => 12,
I_REBOOT => 13,
I_STARTUP_COMPLETE => 14.
};
use constant internalMessageTypes => qw{ I_BATTERY_LEVEL I_TIME I_VERSION I_ID_REQUEST I_ID_RESPONSE
I_INCLUSION_MODE I_CONFIG I_PING I_PING_ACK
I_LOG_MESSAGE I_CHILDREN I_SKETCH_NAME I_SKETCH_VERSION
I_REBOOT I_STARTUP_COMPLETE };
sub internalMessageTypeToStr($) {
(internalMessageTypes)[shift];
}
#-- Sensor types
use constant {
S_DOOR => 0,
S_MOTION => 1,
S_SMOKE => 2,
S_LIGHT => 3,
S_DIMMER => 4,
S_COVER => 5,
S_TEMP => 6,
S_HUM => 7,
S_BARO => 8,
S_WIND => 9,
S_RAIN => 10,
S_UV => 11,
S_WEIGHT => 12,
S_POWER => 13,
S_HEATER => 14,
S_DISTANCE => 15,
S_LIGHT_LEVEL => 16,
S_ARDUINO_NODE => 17,
S_ARDUINO_REPEATER_NODE => 18,
S_LOCK => 19,
S_IR => 20,
S_WATER => 21,
S_AIR_QUALITY => 22,
S_CUSTOM => 23,
S_DUST => 24,
S_SCENE_CONTROLLER => 25,
S_RGB_LIGHT => 26,
S_RGBW_LIGHT => 27,
S_COLOR_SENSOR => 28,
S_HVAC => 29,
S_MULTIMETER => 30,
S_SPRINKLER => 31,
S_WATER_LEAK => 32,
S_SOUND => 33,
S_VIBRATION => 34,
S_MOISTURE => 35,
};
use constant sensorTypes => qw{ S_DOOR S_MOTION S_SMOKE S_LIGHT S_DIMMER S_COVER S_TEMP S_HUM S_BARO S_WIND
S_RAIN S_UV S_WEIGHT S_POWER S_HEATER S_DISTANCE S_LIGHT_LEVEL S_ARDUINO_NODE
S_ARDUINO_REPEATER_NODE S_LOCK S_IR S_WATER S_AIR_QUALITY S_CUSTOM S_DUST S_SCENE_CONTROLLER
S_RGB_LIGHT S_RGBW_LIGHT S_COLOR_SENSOR S_HVAC S_MULTIMETER S_SPRINKLER S_WATER_LEAK S_SOUND
S_VIBRATION S_MOISTURE};
sub sensorTypeToStr($) {
(sensorTypes)[shift];
}
sub sensorTypeToIdx($) {
my $var = shift;
return first { (sensorTypes)[$_] eq $var } 0 .. scalar(sensorTypes);
}
#-- Datastream types
use constant {
ST_FIRMWARE_CONFIG_REQUEST => 0,
ST_FIRMWARE_CONFIG_RESPONSE => 1,
ST_FIRMWARE_REQUEST => 2,
ST_FIRMWARE_RESPONSE => 3,
ST_SOUND => 4,
ST_IMAGE => 5,
};
use constant datastreamTypes => qw{ ST_FIRMWARE_CONFIG_REQUEST ST_FIRMWARE_CONFIG_RESPONSE ST_FIRMWARE_REQUEST ST_FIRMWARE_RESPONSE
ST_SOUND ST_IMAGE };
sub datastreamTypeToStr($) {
(datastreamTypes)[shift];
}
#-- Payload types
use constant {
P_STRING => 0,
P_BYTE => 1,
P_INT16 => 2,
P_UINT16 => 3,
P_LONG32 => 4,
P_ULONG32 => 5,
P_CUSTOM => 6,
};
use constant payloadTypes => qw{ P_STRING P_BYTE P_INT16 P_UINT16 P_LONG32 P_ULONG32 P_CUSTOM };
sub payloadTypeToStr($) {
(payloadTypes)[shift];
}
sub subTypeToStr($$) {
my $cmd = shift;
my $subType = shift;
# Convert subtype to string, depending on message type
TYPE: {
$cmd == C_PRESENTATION and do {
$subType = (sensorTypes)[$subType];
last;
};
$cmd == C_SET and do {
$subType = (variableTypes)[$subType];
last;
};
$cmd == C_REQ and do {
$subType = (variableTypes)[$subType];
last;
};
$cmd == C_INTERNAL and do {
$subType = (internalMessageTypes)[$subType];
last;
};
$subType = "<UNKNOWN_$subType>";
}
return $subType;
}
use Exporter ('import');
@EXPORT = ();
@EXPORT_OK = (
commands,
variableTypes,
internalMessageTypes,
sensorTypes,
datastreamTypes,
payloadTypes,
qw(commandToStr
variableTypeToStr
variableTypeToIdx
internalMessageTypeToStr
sensorTypeToStr
sensorTypeToIdx
datastreamTypeToStr
payloadTypeToStr
subTypeToStr
commands
variableTypes
internalMessageTypes
sensorTypes
datastreamTypes
payloadTypes
));
%EXPORT_TAGS = (all => [@EXPORT_OK]);
1;
Jetzt gibt es nur noch 2 Warnungen:
2015.09.11 11:38:25 1: PERL WARNING: Terminating on signal SIGHUP(1)
2015.09.11 11:38:31 1: starting in console mode
2015.09.11 11:38:31 1: Including fhem.cfg
2015.09.11 11:38:31 3: telnetPort: port 7072 opened
2015.09.11 11:38:31 3: WEB: port 8083 opened
2015.09.11 11:38:31 3: WEBphone: port 8084 opened
2015.09.11 11:38:31 3: WEBtablet: port 8085 opened
2015.09.11 11:38:31 2: eventTypes: loaded 0 events from ./log/eventTypes.txt
Use of uninitialized value in anonymous hash ({}) at ./FHEM/10_MYSENSORS_DEVICE.pm line 193, <$fh> line 38.
Use of uninitialized value in anonymous hash ({}) at ./FHEM/10_MYSENSORS_DEVICE.pm line 194, <$fh> line 38.
2015.09.11 11:38:31 1: Including ./log/fhem.save
2015.09.11 11:38:31 3: No I/O device found for MYSENSOR_102
2015.09.11 11:38:31 3: initialUsbCheck return value: This command is not yet supported on windows
2015.09.11 11:38:31 2: SecurityCheck: WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2015.09.11 11:38:31 0: Featurelevel: 5.6
2015.09.11 11:38:31 0: Server started with 10 defined entities (version $Id: fhem.pl 9163 2015-08-30 07:57:51Z rudolfkoenig $, os MSWin32, user PCE Pilot, pid 3284)
Zitat von: gloob am 11 September 2015, 13:49:17
Hallo
Nachdem ich jetzt die Constants.pm wie folgt angepasst habe scheint es FAST zu gehen
Änderung:
package Device::MySensors::Constants;
use List::Util qw(first);
#-- Message types
use constant {
C_PRESENTATION => 0,
C_SET => 1,
C_REQ => 2,
C_INTERNAL => 3,
C_STREAM => 4,
};
use constant commands => qw( C_PRESENTATION C_SET C_REQ C_INTERNAL C_STREAM );
sub commandToStr($) {
(commands)[shift];
}
#-- Variable types
use constant {
V_TEMP => 0,
V_HUM => 1,
V_LIGHT => 2,
V_DIMMER => 3,
V_PRESSURE => 4,
V_FORECAST => 5,
V_RAIN => 6,
V_RAINRATE => 7,
V_WIND => 8,
V_GUST => 9,
V_DIRECTION => 10,
V_UV => 11,
V_WEIGHT => 12,
V_DISTANCE => 13,
V_IMPEDANCE => 14,
V_ARMED => 15,
V_TRIPPED => 16,
V_WATT => 17,
V_KWH => 18,
V_SCENE_ON => 19,
V_SCENE_OFF => 20,
V_HEATER => 21,
V_HEATER_SW => 22,
V_LIGHT_LEVEL => 23,
V_VAR1 => 24,
V_VAR2 => 25,
V_VAR3 => 26,
V_VAR4 => 27,
V_VAR5 => 28,
V_UP => 29,
V_DOWN => 30,
V_STOP => 31,
V_IR_SEND => 32,
V_IR_RECEIVE => 33,
V_FLOW => 34,
V_VOLUME => 35,
V_LOCK_STATUS => 36,
V_DUST_LEVEL => 37,
V_VOLTAGE => 38,
V_CURRENT => 39,
V_RGB => 40,
V_LEVEL => 41,
V_STATUS => 42,
V_RGBW => 43,
V_PERCENTAGE => 44,
V_ID => 45,
V_UNIT_PREFIX => 46,
V_HVAC_SETPOINT_HEAT => 47,
V_HVAC_SETPOINT_COLD => 48,
V_HVAC_FLOW_STATE => 49,
V_HVAC_FLOW_MODE => 50,
V_HVAC_SPEED => 51,
};
use constant variableTypes => qw{ V_TEMP V_HUM V_LIGHT V_DIMMER V_PRESSURE V_FORECAST V_RAIN
V_RAINRATE V_WIND V_GUST V_DIRECTION V_UV V_WEIGHT V_DISTANCE
V_IMPEDANCE V_ARMED V_TRIPPED V_WATT V_KWH V_SCENE_ON V_SCENE_OFF
V_HEATER V_HEATER_SW V_LIGHT_LEVEL V_VAR1 V_VAR2 V_VAR3 V_VAR4 V_VAR5
V_UP V_DOWN V_STOP V_IR_SEND V_IR_RECEIVE V_FLOW V_VOLUME V_LOCK_STATUS
V_DUST_LEVEL V_VOLTAGE V_CURRENT V_RGB V_LEVEL V_STATUS V_RGBW V_PERCENTAGE V_ID
V_UNIT_PREFIX V_HVAC_SETPOINT_HEAT V_HVAC_SETPOINT_COLD V_HVAC_FLOW_STATE V_HVAC_FLOW_MODE
V_HVAC_SPEED};
sub variableTypeToStr($) {
(variableTypes)[shift];
}
sub variableTypeToIdx($) {
my $var = shift;
return first { (variableTypes)[$_] eq $var } 0 .. scalar(variableTypes);
}
#-- Internal messages
use constant {
I_BATTERY_LEVEL => 0,
I_TIME => 1,
I_VERSION => 2,
I_ID_REQUEST => 3,
I_ID_RESPONSE => 4,
I_INCLUSION_MODE => 5,
I_CONFIG => 6,
I_PING => 7,
I_PING_ACK => 8,
I_LOG_MESSAGE => 9,
I_CHILDREN => 10,
I_SKETCH_NAME => 11,
I_SKETCH_VERSION => 12,
I_REBOOT => 13,
I_STARTUP_COMPLETE => 14.
};
use constant internalMessageTypes => qw{ I_BATTERY_LEVEL I_TIME I_VERSION I_ID_REQUEST I_ID_RESPONSE
I_INCLUSION_MODE I_CONFIG I_PING I_PING_ACK
I_LOG_MESSAGE I_CHILDREN I_SKETCH_NAME I_SKETCH_VERSION
I_REBOOT I_STARTUP_COMPLETE };
sub internalMessageTypeToStr($) {
(internalMessageTypes)[shift];
}
#-- Sensor types
use constant {
S_DOOR => 0,
S_MOTION => 1,
S_SMOKE => 2,
S_LIGHT => 3,
S_DIMMER => 4,
S_COVER => 5,
S_TEMP => 6,
S_HUM => 7,
S_BARO => 8,
S_WIND => 9,
S_RAIN => 10,
S_UV => 11,
S_WEIGHT => 12,
S_POWER => 13,
S_HEATER => 14,
S_DISTANCE => 15,
S_LIGHT_LEVEL => 16,
S_ARDUINO_NODE => 17,
S_ARDUINO_REPEATER_NODE => 18,
S_LOCK => 19,
S_IR => 20,
S_WATER => 21,
S_AIR_QUALITY => 22,
S_CUSTOM => 23,
S_DUST => 24,
S_SCENE_CONTROLLER => 25,
S_RGB_LIGHT => 26,
S_RGBW_LIGHT => 27,
S_COLOR_SENSOR => 28,
S_HVAC => 29,
S_MULTIMETER => 30,
S_SPRINKLER => 31,
S_WATER_LEAK => 32,
S_SOUND => 33,
S_VIBRATION => 34,
S_MOISTURE => 35,
};
use constant sensorTypes => qw{ S_DOOR S_MOTION S_SMOKE S_LIGHT S_DIMMER S_COVER S_TEMP S_HUM S_BARO S_WIND
S_RAIN S_UV S_WEIGHT S_POWER S_HEATER S_DISTANCE S_LIGHT_LEVEL S_ARDUINO_NODE
S_ARDUINO_REPEATER_NODE S_LOCK S_IR S_WATER S_AIR_QUALITY S_CUSTOM S_DUST S_SCENE_CONTROLLER
S_RGB_LIGHT S_RGBW_LIGHT S_COLOR_SENSOR S_HVAC S_MULTIMETER S_SPRINKLER S_WATER_LEAK S_SOUND
S_VIBRATION S_MOISTURE};
sub sensorTypeToStr($) {
(sensorTypes)[shift];
}
sub sensorTypeToIdx($) {
my $var = shift;
return first { (sensorTypes)[$_] eq $var } 0 .. scalar(sensorTypes);
}
#-- Datastream types
use constant {
ST_FIRMWARE_CONFIG_REQUEST => 0,
ST_FIRMWARE_CONFIG_RESPONSE => 1,
ST_FIRMWARE_REQUEST => 2,
ST_FIRMWARE_RESPONSE => 3,
ST_SOUND => 4,
ST_IMAGE => 5,
};
use constant datastreamTypes => qw{ ST_FIRMWARE_CONFIG_REQUEST ST_FIRMWARE_CONFIG_RESPONSE ST_FIRMWARE_REQUEST ST_FIRMWARE_RESPONSE
ST_SOUND ST_IMAGE };
sub datastreamTypeToStr($) {
(datastreamTypes)[shift];
}
#-- Payload types
use constant {
P_STRING => 0,
P_BYTE => 1,
P_INT16 => 2,
P_UINT16 => 3,
P_LONG32 => 4,
P_ULONG32 => 5,
P_CUSTOM => 6,
};
use constant payloadTypes => qw{ P_STRING P_BYTE P_INT16 P_UINT16 P_LONG32 P_ULONG32 P_CUSTOM };
sub payloadTypeToStr($) {
(payloadTypes)[shift];
}
sub subTypeToStr($$) {
my $cmd = shift;
my $subType = shift;
# Convert subtype to string, depending on message type
TYPE: {
$cmd == C_PRESENTATION and do {
$subType = (sensorTypes)[$subType];
last;
};
$cmd == C_SET and do {
$subType = (variableTypes)[$subType];
last;
};
$cmd == C_REQ and do {
$subType = (variableTypes)[$subType];
last;
};
$cmd == C_INTERNAL and do {
$subType = (internalMessageTypes)[$subType];
last;
};
$subType = "<UNKNOWN_$subType>";
}
return $subType;
}
use Exporter ('import');
@EXPORT = ();
@EXPORT_OK = (
commands,
variableTypes,
internalMessageTypes,
sensorTypes,
datastreamTypes,
payloadTypes,
qw(commandToStr
variableTypeToStr
variableTypeToIdx
internalMessageTypeToStr
sensorTypeToStr
sensorTypeToIdx
datastreamTypeToStr
payloadTypeToStr
subTypeToStr
commands
variableTypes
internalMessageTypes
sensorTypes
datastreamTypes
payloadTypes
));
%EXPORT_TAGS = (all => [@EXPORT_OK]);
1;
Jetzt gibt es nur noch 2 Warnungen:
Sorry die Datei hatte ich ganz übersehen. Probiere mal: https://raw.githubusercontent.com/Kolbi/fhem-mirror/patch-1/fhem/FHEM/lib/Device/MySensors/Constants.pm
Hallo Gemeinde,
wie versprochen habe ich mir das Gateway mit dem ESP12 mal nachgebaut.
Die Arduino Konsole gibt folgendes aus.
ESP8266 MySensors Gateway
Connecting to DerNetteNachbar
................................Connected!
IP: 192.168.178.42
0;0;3;0;9;gateway started, id=0, parent=0, distance=0
0;0;3;0;9;read: 100-100-0 s=3,c=1,t=16,pt=2,l=2,sg=0:1
100;3;1;0;16;1
und in fhem:
DEF
192.168.178.42:5003
DeviceName
192.168.178.42:5003
FD
66
NAME
gateway
NOTIFYDEV
global
NR
33
NTFY_ORDER
50-gateway
PARTIAL
STATE
startup complete
TYPE
MYSENSORS
ack
1
inclusion-mode
0
outstandingAck
0
version
1.4.1
Readings
connection
startup complete
2015-09-12 21:18:55
state
opened
2015-09-12 21:18:55
ich habe die IP in Fhem auch eingetragen, jedoch werden die Sensoren nicht erkannt.
Frage: ist der Sketch für die 1.5er Version
gibt es da sonst noch was zu beachten?
LG
/robin
was heißt nicht erkannt? Hast Du sie angelegt und dein gateway als io eingetragen?
Zur Version: wenn Du mit 1.5-lib kompiliert hast, dann ist auch sketch 1.5.
Signierung wird jedoch (noch?) nicht unterstützt.
ich hatte meine mysensors mit dem lan gateway laufen.
jetzt habe ich einfach nur in den defs die ip geändert und neu gestartet.
die vorhandenen sensoren werden da nicht empfangen
Doch, werden aber ignoriert. Es werden nur diejenigen von einem Gateway berücksichtigt, die diesen als io eingetragen haben.
Zitat von: Peter_64 am 11 September 2015, 11:25:12
das Problem mit den Abbrüchen LAN Gateway habe ich auch. Welche Befehle startest Du mit Deinem at genau ?
Ist recht primitiv:
define trigger_ms_reconnect at +*00:01:00 set mysensors_lan connect
Am ioDEV habe ich nichts geändert, heißt bei mir immer noch "gateway". Lediglich das alte Gateway habe ich auf disconneted gestellt, in den DEFS die neue IP vom WLAN-Gateway eingetragen und in Fhem abgespeichert.
Ich habe mal den softwaremäßigen inclusion mode eingeschaltet. Kann es sein, das die sensoren alle eine neue Kanal - ID bekommen haben?
Ich sehe am Blinken der WLAN-Diode auf dem ESP-12 das da was gesendet / empfangen wird, jedoch beim fhem kommt nix an.
Mein log in fhem mit verbose 5 schweigt sich auch aus.
2015.09.13 09:05:18 1: 192.168.178.42:5003 disconnected, waiting to reappear (gateway)
2015.09.13 09:05:20 1: 192.168.178.42:5003 reappeared (gateway)
2015.09.13 09:05:20 5: MYSENSORS send: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=002(I_VERSION ) ack=0 ''
2015.09.13 09:05:20 5: SW: 303b303b333b303b323b0a
2015.09.13 09:05:20 5: MYSENSORS/RAW: /0;0;3;0;14;Gateway startup complete.
2015.09.13 09:05:20 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=014(I_STARTUP_COMPLETE) ack=0 'Gateway startup complete.'
sending systemCode[10011] unitCode[5] command[1]
sending systemCode[10011] unitCode[5] command[1]
sending systemCode[10011] unitCode[5] command[1]
telnet
Last login: Sun Sep 13 17:28:43 on ttys000
MacBookPro:~ Robin$ telnet 192.168.178.42 5003
Trying 192.168.178.42...
Connected to esp826601.fritz.box.
Escape character is '^]'.
0;0;3;0;14;Gateway startup complete.
103;1;1;0;23;128
100;3;1;0;16;0
100;3;1;0;16;1
1;0;1;0;23;102
100;3;1;0;16;0
1;0;1;0;23;103
1;0;1;0;23;75
100;3;1;0;16;1
1;0;1;0;23;75
im Telnet kommt alles an, nur in Fhem wird der Status nicht aktualisiert.
So genau habe ich es nicht getestet. Im Telnet sehen die Ausgaben gut aus, FHEM schlücht das auch. Evtl. ein Problem mit 'line endings'. Ich muss mir das die tage genauer ansehen.
'n Abend!
Habe die 1.5-Patch ausprobiert. Abgesehen vonCompile-Fehler (in Constants steht korrekt V_HVAC_SETPOINT_COOL und in DEVICE irrtümlicherweise V_HVAC_SETPOINT_COLD) funktioniert bei meinen Sensoren brightness-Reading nicht mehr (verschwindet einfach). Ich habe zu dieser späten Stunde nicht mehr genau reingeschaut, da muss aber etwas mit Konstanten verdreht sein. So z.B. ist laut MySensors-API V_LIGHT_LEVEL = 23, in dieser Version jedoch 21.
Grüße,
Alexander
Zitat von: hexenmeister am 15 September 2015, 01:11:42
'n Abend!
Habe die 1.5-Patch ausprobiert. Abgesehen vonCompile-Fehler (in Constants steht korrekt V_HVAC_SETPOINT_COOL und in DEVICE irrtümlicherweise V_HVAC_SETPOINT_COLD) funktioniert bei meinen Sensoren brightness-Reading nicht mehr (verschwindet einfach). Ich habe zu dieser späten Stunde nicht mehr genau reingeschaut, da muss aber etwas mit Konstanten verdreht sein. So z.B. ist laut MySensors-API V_LIGHT_LEVEL = 23, in dieser Version jedoch 21.
Grüße,
Alexander
Hallo Alexander, ich nehme an du meinst meinen 1.5-Patch?
Danke für das Feedback ich schaue es mir gleich einmal an.
Habe es überarbeitet:
https://raw.githubusercontent.com/Kolbi/fhem-mirror/patch-1/fhem/FHEM/lib/Device/MySensors/Constants.pm
https://raw.githubusercontent.com/Kolbi/fhem-mirror/patch-1/fhem/FHEM/10_MYSENSORS_DEVICE.pm
Hallo Leute
Bisher habe ich das Forum nur lesend verwendet, das soll sich nun ändern... ;)
Zuerst einmal ein grosses Dankeschön an die aktiven Coder hier. Ich bin gespannt auf die Integration der neuen MySensors Version 1.5, vor allem wegen der Möglichkeit der Signatur.
Noch eine Frage zu einem Problem, auf das ich heute gestossen bin. Beim Versuch von einem Sensor aus die aktuelle Zeit per requestTime vom Controller abzufragen habe ich keine Antwort erhalten. Ist das eventuell in diesem Fhem Modul nicht implementiert? Ich habe versucht das im Code nachzuvollziehen, habs aber nicht wirklich gefunden. Die Kommunikation läuft sonst Problemlos in beide Richtungen.
Vielen Dank für Hinweise und eure Hilfe
@Hauswart
leider noch nicht. In 00_MYSENSORS.pm muss auch I_STARTUP_COMPLETE(Zeile 345) entsprechend der Änderung ersetzt werden (I_GATEWAY_READY). Schlimmer ist, dass Telegram von meinem Sensor (Licht und Bewegung) immer noch als V_HVAC_FLOW_STATE erkannt wird. Klingt diesmal nach einer Verschiebung (wegen zwei zusätzlichen Variablen, die umbenannt wurden und jetzt doppel vorliegen: V_STATUS => 2, V_LIGHT => 2, V_PERCENTAGE => 3, V_DIMMER => 3,..) in variableTypes.
@Hexenmeister,
hast du mal nachgeschaut, warum das WLAN-Gateway noch nicht 100% funktioniert. Ist bestimmt nur eine kleine Sache.
Ich habe mir ein paar NodeMCUs bestellt um das zu testen.
LG
/robin
Leider etwas wenig Zeit gerade, bin noch nicht dazu gekommen. Dürfte aber nichts schwerwiegendes sein, denn in der Console sehen die Nachrichten gut aus.
Zitat von: hexenmeister am 16 September 2015, 23:14:35
@Hauswart
leider noch nicht. In 00_MYSENSORS.pm muss auch I_STARTUP_COMPLETE(Zeile 345) entsprechend der Änderung ersetzt werden (I_GATEWAY_READY). Schlimmer ist, dass Telegram von meinem Sensor (Licht und Bewegung) immer noch als V_HVAC_FLOW_STATE erkannt wird. Klingt diesmal nach einer Verschiebung (wegen zwei zusätzlichen Variablen, die umbenannt wurden und jetzt doppel vorliegen: V_STATUS => 2, V_LIGHT => 2, V_PERCENTAGE => 3, V_DIMMER => 3,..) in variableTypes.
Danke, ich war mir nicht ganz sicher aus der API-Doku ob die "alten" Variablen V_LIGHT und V_DIMMER ganz entfernt werden:
https://raw.githubusercontent.com/Kolbi/fhem-mirror/patch-1/fhem/FHEM/10_MYSENSORS_DEVICE.pm
https://raw.githubusercontent.com/Kolbi/fhem-mirror/patch-1/fhem/FHEM/lib/Device/MySensors/Constants.pm
00_MYSENSORS.pm muss man nehme ich an nicht zwingend anpassen, auch wenn die neuen internen Variablen so natürlich nicht mit FHEM funktionieren. Mein erstes Ziel - Perl als Programmiersprache ist mir ziemlich fremd - das Modul halbwegs lauffähig mit 1.5 zu bekommen :)
Zitat von: Hauswart am 17 September 2015, 08:32:31
00_MYSENSORS.pm muss man nehme ich an nicht zwingend anpassen.
Doch eigentlich schon.
Ansonsten funktioniert bei mir. Ich beobachte das erstmal paar Tage.
Danke!
Gibt es jetzt schon eine Version die vollständig umgesetzt ist und ohne Fehler eingebunden werden kann?
Ich würde gerne die V_RGB Variable nutzen um RGB Lampen zu steuern.
Zitat von: gloob am 28 September 2015, 14:00:29
Gibt es jetzt schon eine Version die vollständig umgesetzt ist und ohne Fehler eingebunden werden kann?
Ich würde gerne die V_RGB Variable nutzen um RGB Lampen zu steuern.
Hexenmeister verwendet nun wohl schon seit 11 Tagen meine Version...
Zitat von: Hauswart am 28 September 2015, 14:15:55
Hexenmeister verwendet nun wohl schon seit 11 Tagen meine Version...
Bis jetzt nichts zu mekern, wird wohl auch nicht mehr sein ;)
Allerdings fällt mir gerade ein, dass ich gestern ein Update gemacht habe, muss abends nachsehen, ob die Version nicht wieder durch die alte ersetzt wurde.
Die neuen Features verwende ich jedoch derzeit nicht. Wäre also sehr passend, wenn jemand den Test in diese Richtung übernimmt ;)
Zitat von: hexenmeister am 28 September 2015, 14:22:46
Bis jetzt nichts zu mekern, wird wohl auch nicht mehr sein ;)
Allerdings fällt mir gerade ein, dass ich gestern ein Update gemacht habe, muss abends nachsehen, ob die Version nicht wieder durch die alte ersetzt wurde.
Die neuen Features verwende ich jedoch derzeit nicht. Wäre also sehr passend, wenn jemand den Test in diese Richtung übernimmt ;)
Hallo Alex,
ich habe Deine Multisensoren + Programm am laufen. Kann ich auf die MySensor Version 1.5 umstellen, und muss an Deinem Sketch vorab etwas geändert werden.
Ist folgender Ablauf richtig.
1. Die neue 1.5 Mysensor Version in der Arduino - Umgebung installieren
2. Die 10_MYSENSORS_DEVICE.pm + Constants.pm in fhem ersetzen
3. Die Gateways und alle Sensoren nochmal neu beschreiben.
Wichtig auch die 00_MYSENSORS.pm müsst ihr updaten.
Also:
https://raw.githubusercontent.com/Kolbi/fhem-mirror/patch-1/fhem/FHEM/00_MYSENSORS.pm
https://raw.githubusercontent.com/Kolbi/fhem-mirror/patch-1/fhem/FHEM/10_MYSENSORS_DEVICE.pm
https://raw.githubusercontent.com/Kolbi/fhem-mirror/patch-1/fhem/FHEM/lib/Device/MySensors/Constants.pm
Zitat von: Peter_64 am 28 September 2015, 16:10:53
Hallo Alex,
ich habe Deine Multisensoren + Programm am laufen. Kann ich auf die MySensor Version 1.5 umstellen, und muss an Deinem Sketch vorab etwas geändert werden.
Ist folgender Ablauf richtig.
1. Die neue 1.5 Mysensor Version in der Arduino - Umgebung installieren
2. Die 10_MYSENSORS_DEVICE.pm + Constants.pm in fhem ersetzen
3. Die Gateways und alle Sensoren nochmal neu beschreiben.
Hallo Peter,
Kannst Du, musst aber nicht unbedint. Die 'alten' Sensoren werden auch mit neuen FHEM-Modulen laufen. Wenn Du neu mit Version 1.5 kompilieren will, ist eine kleine Änderung nötig. Nimm einfach die neue Version aus GitHub.
Grüße,
Alexander
Zitat von: Hauswart am 28 September 2015, 18:15:53
Wichtig auch die 00_MYSENSORS.pm müsst ihr updaten.
Also:
https://raw.githubusercontent.com/Kolbi/fhem-mirror/patch-1/fhem/FHEM/00_MYSENSORS.pm
https://raw.githubusercontent.com/Kolbi/fhem-mirror/patch-1/fhem/FHEM/10_MYSENSORS_DEVICE.pm
https://raw.githubusercontent.com/Kolbi/fhem-mirror/patch-1/fhem/FHEM/lib/Device/MySensors/Constants.pm
Wenn jemand mal die neuen Features getestet hat, würde ich vorschlagen, die Änderungen einzuchecken. ;)
Funktioniert bei euch das zuweisen einer Node ID für einen neuen Sensor mit Version 1.5?
Habe ich noch nicht getestet, hast du einen Logeintrag oder Ähnliches?
Hallo
kann man ev. die Anleitung aus dem FHem Wiki ergänzen ?
Ich habe dort den Link zu der Word Datei gepostet, die man einfach ändern ergänzen kann....
http://www.fhemwiki.de/wiki/ESP8266
Ich würde das Ganze dann fürs Wiki nacharbeiten, ev hilft es ja dem einen oder anderen Anfänger
Bin halt auch kein EDV Profi und benötige auch immer wieder einfach mehr Infos
Zitat von: Franz Tenbrock am 29 September 2015, 16:59:06
Hallo
kann man ev. die Anleitung aus dem FHem Wiki ergänzen ?
Ich habe dort den Link zu der Word Datei gepostet, die man einfach ändern ergänzen kann....
http://www.fhemwiki.de/wiki/ESP8266
Ich würde das Ganze dann fürs Wiki nacharbeiten, ev hilft es ja dem einen oder anderen Anfänger
Bin halt auch kein EDV Profi und benötige auch immer wieder einfach mehr Infos
Wir sind hier im MySensors Thread ;)
Sorry
ist mir bekannt, aber ich dachte es ging noch hierum ( s.o. )
WLAN-Diode auf dem ESP-12
Bei mysensors hat man ja eine Möglichkeit gefunden des ESP als WLAN Gateway zu nutzen. nebem dem Seriellen und Lan Gateway. Hab mit beidem rumgespielt.
Achso bei der MySensors + ESP-Sache kenne ich mich nicht aus 8)
Hallo,
ich bekomme auch mit den neuen MYSENSORS Modulen keine Verbindung hin und bekomme Exception 28, aber nur bei FHEM. Mit Domoticz geht es aber:
http://forum.fhem.de/index.php/topic,41494.0.html
wenn ich den Beitrag hier lese scheinen einige das WLAN Gateway mit ESP8266 schon mit FHEM im Einsatz zu haben oder?
Zitat von: Samsi am 30 September 2015, 20:34:32
wenn ich den Beitrag hier lese scheinen einige das WLAN Gateway mit ESP8266 schon mit FHEM im Einsatz zu haben oder?
Ich habe es nachgebaut und mit Putty nachgesehen, dass die Daten kommen und gut aussehen. Mit FHEM habe ich noch nicht versucht. Will noch tun. Ich vermute, dass Linendings evtl. nicht so sind, wie FHEM erwartet.
Zitat von: hexenmeister am 28 September 2015, 21:38:34
Wenn jemand mal die neuen Features getestet hat, würde ich vorschlagen, die Änderungen einzuchecken. ;)
Ich habe gerade die Änderungen von Matthias (Hauswart bzw. User 'Kolbi' auf Github) ins FHEM-SVN übernommen (https://sourceforge.net/p/fhem/code/9341/). Testen konnte ich selber leider nicht - ich hoffe das passt so. Falls nicht, gebt einfach Bescheid.
Gruß,
Norbert
Vielen Dank, werde mal testen. :)
Status WLAN-Gateway? Das wird doch der Knaller, wenn es mit Fhem funktioniert ...
LG
/robin
Zitat von: fh168 am 02 Oktober 2015, 23:18:10
Status WLAN-Gateway? Das wird doch der Knaller, wenn es mit Fhem funktioniert ...
Ihn zu Testen steht immer noch auf meiner TODO-Liste :(
@Hexenmeister:
Wenn du willst, kann ich dir schon einen NodeMCU flashen und dir zuschicken. Ist getestet, siehe unten
Dann hast du Zeit, brauchst dann nur Fhem zurechtzubiegen.
ESP8266 MySensors Gateway
Connecting to Testumgebung
..............................Connected!
IP: 192.168.178.70
0;0;3;0;9;gateway started, id=0, parent=0, distance=0
0;0;3;0;9;read: 100-100-0 s=3,c=1,t=16,pt=2,l=2,sg=0:1
100;3;1;0;16;1
0;0;3;0;9;read: 100-100-0 s=3,c=1,t=16,pt=2,l=2,sg=0:0
100;3;1;0;16;0
Danke fürs Angebot :)
Aber so weit hin ich schon. Ich muss ja "nur fhem zurechtbiegen".
Mein Problem ist gerade die Zeit und zwei weitere Hardwareprojekte :(
Mein Gateway erkennt mittlerweile die Sensoren, aber wie bekomme ich jetzt nen Wert raus?! (Im anderen Thread wollte es mir keiner verraten -.-)
ZitatDEF
100
IODev
gateway
NAME
MYSENSOR_100
NR
38
STATE
humidity
TYPE
MYSENSORS_DEVICE
ack
0
protocol
1.4.2
radioId
100
repeater
0
Was schreibe ich bei stateFormat rein?
"humidity" bringt schon mal nichts...
Hi, solange du keine Readings von deinem Sensor bekommst, kannst du auch kein Stateformat angeben!
Wenn du Radings bekommst, dann trägst du das als Stateformat ein.
Beim Anlernen der Sensoren werden die Readings automatisch erstellt sofern der Sensor richtig funktioniert und richtig programiert ist. Im Sketch werden diese als MyMessage definiert. Schau als erstes mal in der Arduino Software, was die serielle Ausgabe sagt.
Auszug aus meiner Konfiguration eines MySensors-Gerätes als Beispiel:
define EG_GA_MS01 MYSENSORS_DEVICE 117
attr EG_GA_MS01 IODev mysensors
attr EG_GA_MS01 alias MSKombisensor (Garage)
attr EG_GA_MS01 icon motion_detector
attr EG_GA_MS01 mapReading_brightness 1 brightness
attr EG_GA_MS01 mapReading_humidity 4 humidity
attr EG_GA_MS01 mapReading_motion 2 tripped
attr EG_GA_MS01 mapReading_temperature 3 temperature
attr EG_GA_MS01 mode repeater
attr EG_GA_MS01 room Garage
attr EG_GA_MS01 stateFormat T: temperature H: humidity L: brightness
attr EG_GA_MS01 version 1.4.1
Ok, Danke soweit schon mal, das da haut der Sensor raus wenn das Gateway nicht im inclusion mode war und ihn noch nicht kennt:
sensor started, id 100<\n>
send: 100-100-0-0 s=255,c=0,t=17,pt=0,l=5,st=ok:1.4.2<\n>
send: 100-100-0-0 s=255,c=3,t=6,pt=1,l=1,st=ok:0<\n>
send: 100-100-0-0 s=255,c=3,t=11,pt=0,l=8,st=ok:Humidity<\n>
send: 100-100-0-0 s=255,c=3,t=12,pt=0,l=3,st=ok:1.0<\n>
send: 100-100-0-0 s=0,c=0,t=7,pt=0,l=0,st=ok:<\n>
send: 100-100-0-0 s=1,c=0,t=6,pt=0,l=0,st=ok:<\n>
send: 100-100-0-0 s=1,c=1,t=0,pt=7,l=5,st=ok:22.1<\n>
T: 22.10<\r><\n>
send: 100-100-0-0 s=0,c=1,t=1,pt=7,l=5,st=ok:55.4<\n>
H: 55.40<\r><\n>
send: 100-100-0-0 s=1,c=1,t=0,pt=7,l=5,st=ok:22.2<\n>
T: 22.20<\r><\n>
send: 100-100-0-0 s=0,c=1,t=1,pt=7,l=5,st=ok:55.5<\n>
H: 55.50<\r><\n>
send: 100-100-0-0 s=1,c=1,t=0,pt=7,l=5,st=ok:22.1<\n>
T: 22.10<\r><\n>
Aber wehe ich mache die beiden miteinander bekannt, dann habe ich nach jedem Reset das da:
sensor started, id 100<\n>
send: 100-100-0-0 s=255,c=0,t=17,pt=0,l=5,st=ok:1.4.2<\n>
send: 100-100-0-0 s=255,c=3,t=6,pt=1,l=1,st=ok:0<\n>
send: 100-100-0-0 s=255,c=3,t=11,pt=0,l=8,st=ok:Humidity<\n>
send: 100-100-0-0 s=255,c=3,t=12,pt=0,l=3,st=ok:1.0<\n>
send: 100-100-0-0 s=0,c=0,t=7,pt=0,l=0,st=ok:<\n>
send: 100-100-0-0 s=1,c=0,t=6,pt=0,l=0,st=ok:<\n>
send: 100-100-0-0 s=0,c=1,t=1,pt=7,l=5,st=ok:2.0<\n>
H: 2.00<\r><\n>
Tut mir leid, keine Ahnung warum. Aber wozu brauchst Du Inclusion-Modus noch? Dieser wird je nur an FHEM weitergereicht und eine ID hat Dein Sensor ja schon. Lege in FHEM die Konfiguration an und gut ist.
Ich hatte das Device bei FHEM gelöscht und noch einmal neu erstellen lassen, in der Hoffnung dass da etwas schief gelaufen sei.
Hat aber offensichtlich nix gebracht, jetzt verrennt er sich noch mehr:
define MYSENSOR_100 MYSENSORS_DEVICE 100
attr MYSENSOR_100 IODev gateway
attr MYSENSOR_100 mapReading_brightness255 255 brightness
attr MYSENSOR_100 mapReading_id 0 id
attr MYSENSOR_100 mapReading_level255 255 level
attr MYSENSOR_100 mapReading_percentage1 1 percentage
attr MYSENSOR_100 mapReading_temperature 0 temperature
attr MYSENSOR_100 mode node
attr MYSENSOR_100 setReading_down1 1
attr MYSENSOR_100 setReading_percentage1 slider,0,1,100
attr MYSENSOR_100 setReading_stop1 1
attr MYSENSOR_100 setReading_up1 1
attr MYSENSOR_100 version 1.4.2
Das passt doch vorne und hinten nicht.
Läuft das alles denn nur bei mir derart Amok? :-[
Am Code habe ich nichts verändert.
http://www.mysensors.org/build/humidity
Ich verstehe immer weniger...
Wenn Du den Sketch aus Deinem Link verwendest, dann passt diese Konfig schon mal gar nicht.
#define CHILD_ID_HUM 0
#define CHILD_ID_TEMP 1
Daher muss nur humidity auf 0 und temperature auf gemappt werden. Was tun hier brightness, percentage, slider und Co.?
Was ist denn hardwareseitig angeschlossen?
Außerdem würde ich auf Version 1.5 gehen.
Ja, seltsam, ne?
Das ist, was automatisch erstellt wurde.
Der Sensor behauptet das hier zu senden:
send: 100-100-0-0 s=1,c=1,t=0,pt=7,l=5,st=ok:23.0<\n>T: 23.00<\r><\n>
send: 100-100-0-0 s=0,c=1,t=1,pt=7,l=5,st=ok:55.8<\n>H: 55.80<\r><\n>
send: 100-100-0-0 s=1,c=1,t=0,pt=7,l=5,st=ok:22.9<\n>T: 22.90<\r><\n>
send: 100-100-0-0 s=0,c=1,t=1,pt=7,l=5,st=ok:55.9<\n>H: 55.90<\r><\n>
send: 100-100-0-0 s=1,c=1,t=0,pt=7,l=5,st=ok:23.0<\n>T: 23.00<\r><\n>
send: 100-100-0-0 s=1,c=1,t=0,pt=7,l=5,st=ok:22.9<\n>T: 22.90<\r><\n>
send: 100-100-0-0 s=1,c=1,t=0,pt=7,l=5,st=ok:23.0<\n>T: 23.00<\r><\n>
send: 100-100-0-0 s=1,c=1,t=0,pt=7,l=5,st=ok:22.9<\n>T: 22.90<\r><\n>
send: 100-100-0-0 s=1,c=1,t=0,pt=7,l=5,st=ok:23.0<\n>T: 23.00<\r><\n>
send: 100-100-0-0 s=0,c=1,t=1,pt=7,l=5,st=ok:55.8<\n>H: 55.80<\r><\n>
send: 100-100-0-0 s=0,c=1,t=1,pt=7,l=5,st=ok:55.9<\n>H: 55.90<\r><\n>
send: 100-100-0-0 s=1,c=1,t=0,pt=7,l=5,st=ok:22.9<\n>T: 22.90<\r><\n>
send: 100-100-0-0 s=1,c=1,t=0,pt=7,l=5,st=ok:23.0<\n>T: 23.00<\r><\n>
send: 100-100-0-0 s=0,c=1,t=1,pt=7,l=5,st=ok:55.8<\n>H: 55.80<\r><\n>
send: 100-100-0-0 s=1,c=1,t=0,pt=7,l=5,st=ok:23.1<\n>T: 23.10<\r><\n>
send: 100-100-0-0 s=0,c=1,t=1,pt=7,l=5,st=ok:54.8<\n>H: 54.80<\r><\n>
send: 100-100-0-0 s=0,c=1,t=1,pt=7,l=5,st=ok:54.4<\n>H: 54.40<\r><\n>
send: 100-100-0-0 s=0,c=1,t=1,pt=7,l=5,st=ok:53.9<\n>H: 53.90<\r><\n>
Im Logfile steht das da:
Zitat2015.10.04 01:18:14 5: MYSENSORS/RAW: /100;0;1;0;1;55.9
2015.10.04 01:18:14 5: MYSENSORS Read: Rx: fr=100 ci=000 c=001(C_SET ) st=001(V_HUM ) ack=0 '55.9'
2015.10.04 01:18:21 5: MYSENSORS/RAW: /100;1;1;0;0;23.0
2015.10.04 01:18:21 5: MYSENSORS Read: Rx: fr=100 ci=001 c=001(C_SET ) st=000(V_TEMP ) ack=0 '23.0'
2015.10.04 01:18:28 5: MYSENSORS/RAW: /100;1;1;0;0;22.9
2015.10.04 01:18:28 5: MYSENSORS Read: Rx: fr=100 ci=001 c=001(C_SET ) st=000(V_TEMP ) ack=0 '22.9'
2015.10.04 01:18:36 5: MYSENSORS/RAW: /100;1;1;0;0;23.0
Die 1.4.2 stand nur noch so im Sketch drin, die Library ist die 1.5, FHEM habe ich auch vor wenigen Stunden erst aktualisiert.
sieht doch eigentlich gut aus. was passiert, wenn du mapping in konfig korrekt hast, also nur temp/hum?
Dann murkst er sobald der Sensor sich gemeldet hat wieder die Mappings rein die von sonstwoher kommen :o
Sehr komisch, keine Idee. Magst Du mit meinem Sketch versuchen, bei mir tut es sein Dienst ohne Probleme.
https://github.com/hexenmeister/MySensors_MyDevices/blob/master/TempHumLuxMotion/TempHumLuxMotion.ino
Dann bekomme ich das da raus:
(http://www.fingers-welt.de/imghost/up/20151004_1859_79-206-15-224_79-206-15-224_small_ablader_tmp.jpg)->zoom (http://www.fingers-welt.de/imghost/up/20151004_1859_79-206-15-224_79-206-15-224_ablader_tmp.jpg)
und diese mappings wurden automatisch ergänzt? sehr merkwürdig. Doch Probleme mit dem neuen Modul?
Habe jetzt Update ausgeführt, hab also genau die gleiche (neuste) Version. Funktioniert wie vorher. Ich lkann mir kein Reim daras machen.
Evtl. ein Problem mit Autocreate. Mach mal aus, falls noch an und setze wieder Mappings aus meinem Device-Konfig.
Mein Konfig für Gateway:
define mysensors MYSENSORS /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_1003-if00-port0@115200
attr mysensors alias MySensors Gateway
attr mysensors first-sensorid 120
attr mysensors group IO
attr mysensors icon cul_usb
attr mysensors room IO_Devices
attr mysensors stateFormat connection
Ich habe die Ethernetvariante (W5100), die serielle wollte bei mir gar nicht funktionieren.
Ich glaube fast dass das Gateway nicht ganz tut was es soll, werde mir doch das serielle noch einmal aufbauen.
Zitat von: Erdschluss am 04 Oktober 2015, 20:54:02
Ich habe die Ethernetvariante (W5100), die serielle wollte bei mir gar nicht funktionieren.
Ich glaube fast dass das Gateway nicht ganz tut was es soll, werde mir doch das serielle noch einmal aufbauen.
habe beide in Benutzung. Beide problemlos.
define mysensors_lan MYSENSORS 192.168.0.25:5003
attr mysensors_lan alias MySensors Gateway LAN
attr mysensors_lan first-sensorid 10
attr mysensors_lan group IO
attr mysensors_lan icon cul_usb
attr mysensors_lan room IO_Devices
attr mysensors_lan stateFormat connection
Hm. Bis auf kaputes Autocreate in neuem Modul fällt mir erstmal nichts ein.
Ich habe gerade auch das neue Modul getestet. Bei mir werden die readings eines neuen Sensors auch falsch angelegt.
Scheinbar ist mit der neuen version wirklich etwas falsch.
Ich meine zu wissen, wo der Hase im Pfeffer liegt. Mal bitte ohne Autocreate probieren (würde ja selbst machen, passt aber gerade schlecht).
Alle Sensoren die ich vor der neuen version angelernt habe, funktionieren ohne Probleme. Es scheint also wirklich am Create zu liegen
Dann ist der Fall klar, Hauswart sollte sich das mal ansehen. Vlt. schaue ich mir das auch an, komme aber nnicht so schnell zu.
Workaround: Autocreate aus, Konfig per Hand anlegen.
Im GUI kennt autocreate nur 1, also einfach löschen?
Oder gibts da nen impliziten Defaultwert !=0?
Ja, Attribut "autocreate" soll weg.
Ich kloppe mich noch etwas mit dem Attribut-Editor, aber ein "tripped" kommt schon mal durch :D
Hab glaube ich einen Fix für das Autocreate-problem (https://sourceforge.net/p/fhem/code/9385/). @Hauswart hat S_LIGHT als Alias für das neue S_STATUS drin gelassen, das bringt aber die Datenstrukturen für das Autocreate durcheinander in Folge verschieben sich die Devicetypen, die in den Messages ja numerisch übertragen werden um eins, dadurch bekommt Autocreate dann die Mappings für den danebenliegenden Devicetyp.
Das hat auch zur Folge, dass man vorhandene Attribute 'mapReadingType_LIGHT' durch 'mapReadingType_STATUS' ersetzten muss.
Kann es sein, dass es seit heute wieder ein Update gibt?
Nach einem ersten Kurztest per Remoteverbindung, scheint es jetzt die Readings wieder richtig anzulegen.
Ich muss nur noch einmal Testen ob jetzt auch die Node ID wieder richtig gesetzt wird.
Hallo Zusammen, ich war leider von Samstag bis gestern Nachmittag weg und konnte daher nicht eingreifen.
Danke Norbert für den Fix... Da laut API-Definition ist komischerweise S_LIGHT und S_BINARY für den gleichen Wert zuständig?
http://www.mysensors.org/download/serial_api_15
Zitat von: Hauswart am 06 Oktober 2015, 11:41:36
laut API-Definition ist komischerweise S_LIGHT und S_BINARY für den gleichen Wert zuständig?
http://www.mysensors.org/download/serial_api_15
Naja, das von der Logik passt schon, beides ist eben 1 oder 0 vs. ein oder aus. ;)
Zitat von: hexenmeister am 06 Oktober 2015, 12:59:26
Naja, das von der Logik passt schon, beides ist eben 1 oder 0 vs. ein oder aus. ;)
Ich meine, dass beide für Value 3 zuständig sind? Aus meiner Sicht kann nur eine Variable dafür zuständig sein. Hatte mich unglücklich ausgedrückt mit "Wert".
Zitat von: Hauswart am 06 Oktober 2015, 13:02:03
Ich meine, dass beide für Value 3 zuständig sind? Aus meiner Sicht kann nur eine Variable dafür zuständig sein. Hatte mich unglücklich ausgedrückt mit "Wert".
Habe ich schon verstanden. Wäre sicher für die Presentation-Message von Vorteil. Von dem funktionalem Gesichtspunkt jedoch gleichwertig.
ich glaube ich muss meinen Fix heute abend noch mal überarbeiten. So wie es jetzt implementiert ist, sollte autocreate funktionieren - Was bisher als S_LIGHT angelegt worden wäre, erzeugt jetzt halt jetzt ein S_STATUS. Soweit kein Problem (für neu angelernte Sensoren bzw. wenn Autocreate angeschaltet ist).
Nur wenn man schon existierende MYSENSORS_DEVICE definitionen unter Verwendung des mapReadingType_LIGHT-Attribut hat, wird es mit der letzten Änderung wohl auf die Nase fallen (Weil es den String 'LIGHT' in dem Attribut nicht mehr erkennt - das ist generisch implementiert und der String ist ja jetzt draußen aus der Constants.pm).
Nach Update und Neustart liefert der Sensor jetzt auch plausible Werte ;D
Juhu!
Hallo
Mein neu angelernter Sensor liefert als temp und humidity nur noch 1.0 für beides, der Sketch ist vom Hexenmeister auf der von Ihm gezeichneten UP Platine, die alten Sensoren laufen ohne Probleme!
Woran kann das liegen?
Neu
brightness1 21.67 2015-10-09 12:50:10
humidity4 1.0 2015-10-09 12:39:59
temperature3 1.0 2015-10-09 12:39:59
tripped2 on 2015-10-09 12:50:38
Alt
brightness1 45.00 2015-10-09 12:49:02
humidity4 47.3 2015-10-09 12:51:58
temperature3 25.3 2015-10-09 12:51:58
tripped2 on 2015-10-09 12:48:37
Update und shutdown restart habe ich gemacht
wie sieht die Device-Definition aus?
Erste Vermutung: Die mapping-Attribute sind immer noch nicht korrekt, so dass die Werte, die eigentlich als erkannte Bewegung gedacht sind, in die Temp/Hum-Readings reingepresst werden.
Ich will zuhause versuchen, ein neues Devices zusammen zu stecken und anzulernen. Komme aber heute definitiv nicht mehr dazu.
Ok ich löte auch noch einmal den DHT 22 aus nicht das der hin ist!
Zitat von: Eckbert0815 am 09 Oktober 2015, 14:56:45
Ok ich löte auch noch einmal den DHT 22 aus nicht das der hin ist!
Glaube ich eher nicht. Wie sieht FHEM Definition denn aus?
Die sieht so aus!
define MYSENSOR_100 MYSENSORS_DEVICE 100
attr MYSENSOR_100 IODev mysensors_lan
attr MYSENSOR_100 mapReading_armed2 2 armed
attr MYSENSOR_100 mapReading_brightness1 1 brightness
attr MYSENSOR_100 mapReading_humidity4 4 humidity
attr MYSENSOR_100 mapReading_id3 3 id
attr MYSENSOR_100 mapReading_level1 1 level
attr MYSENSOR_100 mapReading_temperature3 3 temperature
attr MYSENSOR_100 mapReading_tripped2 2 tripped
attr MYSENSOR_100 mode repeater
attr MYSENSOR_100 stateFormat brightness1 Lux,humidity4 %,temperature3 C,tripped2
attr MYSENSOR_100 version 1.5
Die alten sehen so aus
define MYSENSOR_102 MYSENSORS_DEVICE 102
attr MYSENSOR_102 IODev mysensors_lan
attr MYSENSOR_102 alias Kueche_Temp_Lux_Motion
attr MYSENSOR_102 group MySensors
attr MYSENSOR_102 icon motion_detector
attr MYSENSOR_102 mapReading_brightness1 1 brightness
attr MYSENSOR_102 mapReading_humidity4 4 humidity
attr MYSENSOR_102 mapReading_temperature3 3 temperature
attr MYSENSOR_102 mapReading_tripped2 2 tripped
attr MYSENSOR_102 mode repeater
attr MYSENSOR_102 room Kueche
attr MYSENSOR_102 stateFormat brightness1 Lux,humidity4 %,temperature3 C,tripped2
attr MYSENSOR_102 version 1.5
Hm... Sind schon paar mehr. Hilft es, wenn man die zusätzlichen mappings entfernt? Kannst Du ggf. den Sensor über die Serielle Schnittstelle beobachten, um zu sehen, dass die Daten korrekt gesendet werden?
Wenn der Sensor nach dem manuellen entfernen der überflüssigen Readings funktioniert. Kannst du dann bitte noch einmal den kompletten Sensor löschen und neu anlernen?
Mich würde interessieren, ob das Modul wirklich noch einen Fehler hat...
Hm so, habe die Readings entfernt! was soll ich sagen läuft sofort richtig!
Merkwürdig
brightness1 65.00 2015-10-09 16:36:11
humidity4 54.6 2015-10-09 16:35:03
temperature3 23.8 2015-10-09 16:35:03
tripped2 on 2015-10-09 16:35:48
Autocreate erstellt die readings sofort wieder. Mit gleichen Ergebnis
Zitat von: Eckbert0815 am 09 Oktober 2015, 16:39:17
Autocreate erstellt die readings sofort wieder. Mit gleichen Ergebnis
Die fehlerhaften?
So wenn ich den Sensor lösche und dann neu anmelde, dann passiert folgendes, es fehlen einige readings, mal die Temperatur, mal Luftfeuchtigkeit, oder Helligkeit.
Wenn ich das ganze ein paar mal wiederhole, dann sind alle readings da! aber diese hier kommen immer!
mapReading_armed2
mapReading_level1
mapReading_id3
Über die Serielle Schnittstelle kommen die richtigen Werte
Nach einem Neustart des Sensors werden die
mapReading_armed2
mapReading_level1
mapReading_id3
auch wieder angelegt!
Autocreate ist also immer noch nicht ganz korrekt.
scheint so!
Hast du mir bitte den Link zu Alex seinem Sketch?
https://github.com/hexenmeister/MySensors_MyDevices/blob/master/TempHumLuxMotion/TempHumLuxMotion.ino#L1
Fehler scheint in der https://github.com/Kolbi/fhem-mirror/commits/master/fhem/FHEM/10_MYSENSORS_DEVICE.pm zu sein. Hätte lediglich Zeit für einen Quick Dirty Fix.
Na das ist doch schonmal was!
S_MOTION => { receives => [], sends => [V_TRIPPED,V_ARMED] }, # MotionSensor
S_TEMP => { receives => [], sends => [V_TEMP,V_ID] }, # Temperature sensor
S_HUM => { receives => [], sends => [V_HUM] }, # Humidity sensor
S_LIGHT_LEVEL => { receives => [], sends => [V_LIGHT_LEVEL,V_LEVEL] }, # Light sensor
Mir ist z.B. derzeit unklar, wieso S_TEMP mit der API 1.5 V_ID dazubekommen hat..
Mit dieser Version wird es wohl gehen denke ich: https://raw.githubusercontent.com/Kolbi/fhem-mirror/patch-2/fhem/FHEM/10_MYSENSORS_DEVICE.pm
Ich teste es gleich....feedback folgt
Noch nicht ganz, die fehlerhaften readings sind jetzt weg, aber nach dem ersten neu anlernen, war nur das reading tripped2 da, nach einem weiteren reset kam humidity4 dazu.
temperature3 und brightness1 fehlen.
Device gelöscht, reset und es kam nur temperature3, wieder reset und es kam humidity4 hinzu, der Rest fehlt.
............................Wenn ich den Sensor direkt in der CFG anlege dann funktioniert alles wie es soll!
ich bin dieses WE unterwegs und kann erst Sonntag Abend oder Montag im Detail draufschauen.
@Hauswart: wenn du einen fix hast, der funktioniert, schick mir nenn Pullrequest...
Hallo zusammen,
es freut mich, dass hier die Integration von MySensors so vorbildlich weiterbetrieben wird. Mein Umstieg auf MySensors API 1.5 und die neuen FHEM-Module hat problemlos funtioniert, ich mußte bisher nur Dimmer gegen percentage sowie Light gegen status austauschen. Viel mehr nutze ich aber im Moment nicht.
Im mySensors Forum bin ich auf einen Post gestoßen, der ein Display zur Darstellung von Sensor- oder Gateway- Daten beschreibt. Das ist wohl noch nicht implementiert, soll aber in der nächsten Version drin sein, im Development ist es bereits.
Hier der Post: http://forum.mysensors.org/topic/1957/lcd-clock-and-text-sensor-node-with-new-v_text (http://forum.mysensors.org/topic/1957/lcd-clock-and-text-sensor-node-with-new-v_text)
In der message.h von MySensors (aus der Develop-Version 1.5), wo die Definitionen abgelegt sind, sind nun V_TEXT, S_INFO und S_GAS neu dazugekommen.
Frage an die gerade aktive "Truppe": könnt ihr das gleich mit in fhem einbauen? Sobald die Neuerung in mySensors dann kommt könnte man es ja nutzen (oder mit der Develop-Version jetzt schon testen).
Ich bin immer noch dran, Displays für die Haussteuerung zu erstellen, bisher habe ich das mittels LAN gemacht, denke aber per mysensors wäre das erheblich besser, da nur noch eine Stromversorgung nötig ist und kein Netzwerkanschluss mehr.
In diesem Besipiel:
http://forum.mysensors.org/topic/1817/weather-display-for-swedish-fhem-users (http://forum.mysensors.org/topic/1817/weather-display-for-swedish-fhem-users)
wurde etwas ähnliches realisiert, allerdings mittels SCENE und LIGHT und diversen VAR_x dazu, das ginge wohl auch, aber die V_TEXT lösung wäre wohl der direktere oder logischere Weg.
Ich würde mich sehr freuen!
Viele Grüße
Sany
Hier gibt es schon einmal etwas ähnliches um HEX Werte zu senden.
http://forum.fhem.de/index.php/topic,37341.0.html (http://forum.fhem.de/index.php/topic,37341.0.html)
Vielleicht hilft dir das schon weiter.
Zitat von: fh168 am 03 Oktober 2015, 11:16:57
Dann hast du Zeit, brauchst dann nur Fhem zurechtzubiegen.
Wie in einem anderen Thread gerade gepostet (sorry für Doppelpost):
Zitat von: hexenmeister am 11 Oktober 2015, 14:04:07
So Jungs (and Mädels, if any ;) )
Von dem schlechten Gewissen leicht geplagt (hab ja versprochen), habe mich heute kurz hingesetzt ud die ganze Sache angeschaut. Wie erwartet, hat FHEM Probleme mit nicht vorhandenen Zeilenumbrüchen.
Bitte testet mal diesen Sketch hier: https://github.com/hexenmeister/MySensors_MyDevices/tree/master/MyEsp8266Gateway
Bei mir tut jetzt wie es soll. Zu Stabilität kann ich nichts sagen, läuft erst seit 1 Stunde.
Ich habe es mal durchgerappelt.
Esp8266Gateway.ino:85:22: fatal error: MySecret.h: No such file or directory
compilation terminated.
Fehler beim Kompilieren.
Die alte Version lief einwandfrei durch.
EDIT: MySecret.h ist die eine neue Definitions-Datei für SSID und Passwort... ok
rennt jetzt durch.
edit2:
Die Werte kommen fehlerhaft rüber, aber ... trarahhh -> sie laufen jetzt in Fhem auf. Auf meinen Sensoren habe ich noch die 1.4.1 drauf.
CHANGED
DEF
1
IODev
gateway
NAME
MQ2SENSOR
NR
1678
STATE
771751989
TYPE
MYSENSORS_DEVICE
ack
0
protocol
1.4.1
radioId
1
repeater
0
da sollte 53 rauskommen
Client 0 disconnected
0;0;3;0;9;read: 1-1-0 s=0,c=1,t=23,pt=2,l=2,sg=0:771751989
1;0;1;0;23;771751989
0;0;3;0;9;read: 1-1-0 s=0,c=1,t=23,pt=2,l=2,sg=0:771751988
1;0;1;0;23;771751988
0;0;3;0;9;read: 1-1-0 s=0,c=1,t=23,pt=2,l=2,sg=0:771751989
1;0;1;0;23;771751989
0;0;3;0;9;read: 1-1-0 s=0,c=1,t=23,pt=2,l=2,sg=0:771751989
1;0;1;0;23;771751989
0;0;3;0;9;read: 1-1-0 s=0,c=1,t=23,pt=2,l=2,sg=0:771751989
1;0;1;0;23;771751989
LG
/robin
Hallo Robin,
ich habe die Anmeldedaten in eine extra-Datei gepackt, damit ich das Sketch unverändert und ohne meine Passwörte einchecken kann.
Was und welche Werte sind fehlerhaft? Der gateway ist ja dafür eher nicht verantwortlich, der ist nur der Vermittler.
Mag an der späten Stunde liegen, aber ich habe Dein Problem noch nicht erfasst ;)
Moin,
Ich hatte einfach den neuen Code genommen und vom Gateway ESP8266 Sketch den allten überschrieben.
Der alte lieferte im Serial Monitor vom Sensor den Wert 53 anstatt die 6 stellige Zahl. Also irgendwas muß am Code geändert worden sein, wie auch oben bemerkt die neue MySecret.h Datei.
Ich schaue da heute abend noch mal nach.
Robin
Die einzigen zwei Änderungen sind die Auslagerung von SSID/Passwort und "\n" an jedes gesendeten String anhängen.
Was liefert Dein Sensor über UART, also direkt, ohne Gateway?
moin,
Gestern Abend siehe Screenshot auch die seltsamen Werte.
Hm, habe das Ding gerade nochmal angeschlossen, jetzt liefert er valide Werte. Seltsam... wir beobachten das mal.
Wenn es später mal final läuft, finde ich das genial! Mit nur gefühlt 2 Bauteilen das WLAN-Gateway zusammenzustecken :-). Ich habe mir vor über einem Jahr das Teil mit Nano, ESP8266-1 und LAN zusammengefrickelt und im Blog drüber berichtet. Ist nix für Enduser und Nicht-Löter.
EDIT: Sieht im Kurztest jetzt gut aus, ich lasse das mal durchlaufen :-), vielen Dank nochmal.
Jetzt kann ich endlich das Kabelgedöns in der Ecke entfernen (= Netzwerkkabel) und das WLAN-Gateway irgendwo im Raum platzieren.
LG
/Robin
Hallo Robin,
fasst du das Ganze in deinem Blog zusammen ?
Hab die ESP Teile hier noch rumliegen, aber wenig Zeit und deine Schritt für Schritt Anleitungen sind einfach genial ;D
Ist die Integration der v1.5 jetzt eigentlich abgeschlossen?
Zitat von: fh168 am 14 Oktober 2015, 07:18:45
Mit nur gefühlt 2 Bauteilen das WLAN-Gateway zusammenzustecken :-). Ich habe mir vor über einem Jahr das Teil mit Nano, ESP8266-1 und LAN zusammengefrickelt und im Blog drüber berichtet. Ist nix für Enduser und Nicht-Löter.
Ich überlege, eine PCB dafür zu designen. Nicht-Löter und SMD-Verweigerer habe ich allerdings audrücklich nicht im Fokus ;D
Zitat von: gloob am 14 Oktober 2015, 08:25:53
Ist die Integration der v1.5 jetzt eigentlich abgeschlossen?
Nein. Zumindestens autocreate ist noch fehlerhaft, was allerding IMHO nur ein "Schönheitsfehler" ist.
Hallo Franz,
genau, eine ausführliche Beschreibung mit Youtube Video und einem Beispiel - Sensor habe ich vor.
Der Leser hat dann sofort einen Aha-Effekt. Die MySensors - Module laufen bei mir schon mittlerweile fast ein Jahr
Leider ist mein Blog derzeitig down, ich wechsel gerade den Hoster.
Wird noch ein paar Tage dauern bis alles wieder steht.
LG
/robin
Kurze Frage an die Experten:
Kann man einen Feedback vom Sensor/Gateway/MySensors programmieren, der Fhem dann sagt: Ja, ich habe das Signal erhalten oder die Taste wurde erfolgreich gedrückt? Beim PCA301 ist das so, da sieht man, das die Steckdose geschaltet wurde.
LG
/robin
Zitat von: fh168 am 14 Oktober 2015, 11:32:34
Kann man einen Feedback vom Sensor/Gateway/MySensors programmieren, der Fhem dann sagt: Ja, ich habe das Signal erhalten oder die Taste wurde erfolgreich gedrückt? Beim PCA301 ist das so, da sieht man, das die Steckdose geschaltet wurde.
MySensors kann das (ACK senden). Ich meine, das kann man auch in FHEM-Modul einschalten, ausprobiert habe ich das bis jetzt nicht.
Hi,
ich weiss nicht genau ob ich hier richtig bin aber seit dem ich ein update von FHEM gemacht habe, kommt folgende Fehlermeldung:
2015.10.19 17:47:40 1: reload: Error:Modul 00_MYSENSORS deactivated:
Bareword "I_GATEWAY_READY" not allowed while "strict subs" in use at ./FHEM/00_MYSENSORS.pm line 345, <$fh> line 210.
2015.10.19 17:47:40 0: Bareword "I_GATEWAY_READY" not allowed while "strict subs" in use at ./FHEM/00_MYSENSORS.pm line 345, <$fh> line 210.
Ich habe den SerialAdapter auf Version 1.5 und auch mit der Git-Version von 00_MYSENSORS.pm kommt der Fehler.
Aus der Fhem.cfg
###MYsensor serial
define gateway MYSENSORS /dev/ttyUSB0@115200
#attr gateway requestAck 1
#attr gateway stateFormat connection
Weiss einer woran es liegt ? Vielen Dank für die Hilfe
Die Versionen passen nicht zueinander.
Nimm am besten alle dazugehörigen Dateien: 00_MYSENSORS.pm, 10_MYSENSORS_DEVICE.pm und aus ./FHEM/lib/Device/MySensors die Dateien Constants.pm und Message.pm
Vielen Dank für den Hinweis. Habe jetzt alle vier Datein (00_MYSENSORS.pm, 10_MYSENSORS_DEVICE.pm,Constants.pm und Message.pm) aus dem Git (https://github.com/ntruchsess/fhem-mirror/tree/master/fhem/FHEM). Leider kommt immer noch der gleiche Fehler.
Gibt es noch eine andere möglichkeit woran es liegen könnte ?
Das kann eigentlich nicht sein. In https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/lib/Device/MySensors/Constants.pm ist I_GATEWAY_READY definiert. Hast Du die Dateien an die richtigen Stellen kopiert? (und auch FHEM neugestartet?)
:o ::) neu gestartet und alle geht. Vielen Dank und Sorry
Hi,
ich hab mal ne Frage - irgendwie scheint es bei mir nicht zu funktionieren. Versuchsaufbau ist eigentlich so, wie es Hauswart hier beschrieben hat
http://forum.fhem.de/index.php/topic,31400.msg254082.html#msg254082
ZitatGenau einmal das Gateway: Funk-Modul anschliessen: http://www.mysensors.org/build/connect_radio => Skript: http://www.mysensors.org/build/serial_gateway
Und einmal der Ultraschall-Sensor: Funk-Modul anschliessen: http://www.mysensors.org/build/connect_radio Ultraschallsensor anschliessen + Skript: http://www.mysensors.org/build/distance
Dann hab ich das Gateway in FHEM eingebunden und er steht auf connectet - dann autocrate = 1 gesetzt und inclusion-mode=on - dann das Sensor Modul neu gestartet aber nix passiert. Weiß evtl jemand, wo ich den Fehler gemacht habe?
Was auch komisch ist - im Feld Partials stehen komische Zeichen
ZitatS�0 0 00� �� 000�� 0 00 0�0�00 0 �00 � 0 ��� (00�00� 000� 0 0 0000 0
Vielen Dank schon mal
ich antworte mir mal selber 8)
mit der richtigen Baudrate gehts dann ;D
Mal eine Frage an ntruchsess und hexenmeister,
ich würde gerne auch mal wieder einen Wunsch äußern ;)
Ist es möglich den "I_SKETCH_NAME" und die "I_SKETCH_VERSION" permanent im FHEM zu hinterlegen? Bis sich dieser halt durch ein Update ändert.
Die Variablen werden ja bei Sensorstart (Hardreset / Poweron) übermittelt, wenn man aber den FHEM Server neustartet zwecks Updateinstallation, werden o.g. Variablen nicht mehr angezeigt (der Sensor läuft ja weiter und übermittelt nur die Werte, was ja auch richtig ist).
Es wäre schon hilfreich, wenn man die Softwareversion eines Moduls wüsste, wenn man verschiedene Softwarestände im Einsatz hat. Bei mir laufen die Module ordentlich in einen Gehäuse inkl. Batterie verbaut an den jeweiligen Einsatzort.
Eigentlich habe ich nur die Möglichkeit an den Softwarestand zu kommen, wenn ich die Module öffne und einen Reset durchführe oder die Stromzufuhr unterbreche. Das ist schon ärgerlich. Auch wenn man die Module ggf. Updaten möchte hat man keine Übersicht über die eingesetzte Software und deren Versionsstand.
Wäre das machbar?
Gruß Jens
P.S.: Ich hoffe ich habe mich halbwegs verständlich ausgedrückt, was ich meine.
Zitat von: fh555 am 31 Oktober 2015, 23:09:48
ich würde gerne auch mal wieder einen Wunsch äußern ;)
[...]
Ist es möglich den "I_SKETCH_NAME" und die "I_SKETCH_VERSION" permanent im FHEM zu hinterlegen?
Es ist ja bald Weihnachten ;)
Würde gehen, wenn man diese Infos nicht als INTERNAL, sondern als Readings oder Attribute anlegt. Attribute werden sicher gespeichern (in fhem.cfg), Readings (etwas weniger sicher) in der Statefile. Attribute wäre IMHO der falsche Platz. Damit Readings regelmäßig gespeichert werden, nutze ich folgende Definition:
define TE_NN_SAVE_STATE at +*00:10:00 {WriteStatefile()}Ich habe probeweise die letzte Version gepatcht. Probiere mal aus und wenn die in Deinem Sinne ist, könne ich 'nen Patch an Norbert schicken.
(http://forum.fhem.de/index.php?action=dlattach;topic=26807.0;attach=39693;image)
Was bedeutet denn "Autocreate ist noch fehlerhaft " ?
Ich löte gerade an ein paar Sensoren herum, mal werden die Kanäle angelegt, mal nicht bzw. nur einzelne ?
Habe hier z.B. einen Sensor, der sollte eigentlich Luftfeuchte, Temperatur, Bewegungsmelder und Batteriestatus melden, aber in FHEM taucht nur batterylevel auf.
Ein anderer, identischer Sensor funktioniert.
Ich sehe aber, das die Daten ankommen, unten ein Ausschnitt vom Log nach einem Reset.
Muss ich die Kanäle manuell anlegen ? Falls ja, wie ?
Ich muss aber auch zugeben, ich weiss nicht ob ich die aktuellste Version habe, reicht ein Update von Fhem, oder muss ich eine Version aus Git o.ä. nehmen ?
Viele Grüße
Klaus
2015.11.01 19:34:43.616 5: MYSENSORS Read: Rx: fr=102 ci=255 c=003(C_INTERNAL ) st=011(I_SKETCH_NAME ) ack=0 'Motion Humidity w/ Batt'
2015.11.01 19:34:43.621 5: MYSENSORS Read: Rx: fr=102 ci=255 c=003(C_INTERNAL ) st=012(I_SKETCH_VERSION) ack=0 '1.0'
2015.11.01 19:34:43.627 5: MYSENSORS Read: Rx: fr=102 ci=000 c=000(C_PRESENTATION) st=007(S_HUM ) ack=0 ''
2015.11.01 19:34:43.632 5: MYSENSORS Read: Rx: fr=102 ci=001 c=000(C_PRESENTATION) st=006(S_TEMP ) ack=0 ''
2015.11.01 19:34:43.637 5: MYSENSORS Read: Rx: fr=102 ci=002 c=000(C_PRESENTATION) st=001(S_MOTION ) ack=0 ''
2015.11.01 19:34:43.643 5: MYSENSORS/RAW: /102;255;3;0;0;89
2015.11.01 19:34:43.644 5: MYSENSORS Read: Rx: fr=102 ci=255 c=003(C_INTERNAL ) st=000(I_BATTERY_LEVEL ) ack=0 '89'
2015.11.01 19:34:45.636 5: MYSENSORS/RAW: /102;1;1;0;0;20.0
2015.11.01 19:34:45.638 5: MYSENSORS Read: Rx: fr=102 ci=001 c=001(C_SET ) st=000(V_TEMP ) ack=0 '20.0'
2015.11.01 19:34:45.656 5: MYSENSORS/RAW: /102;0;1;0;1;48.8
2015.11.01 19:34:45.657 5: MYSENSORS Read: Rx: fr=102 ci=000 c=001(C_SET ) st=001(V_HUM ) ack=0 '48.8'
2015.11.01 19:34:46.493 5: MYSENSORS/RAW: /102;2;1;0;16;1
2015.11.01 19:34:46.494 5: MYSENSORS Read: Rx: fr=102 ci=002 c=001(C_SET ) st=016(V_TRIPPED ) ack=0 '1'
2015.11.01 19:34:48.972 5: MYSENSORS/RAW: /102;2;1;0;16;0
2015.11.01 19:34:48.973 5: MYSENSORS Read: Rx: fr=102 ci=002 c=001(C_SET ) st=016(V_TRIPPED ) ack=0 '0'
Versuch einfach mal mehrfach den Sensor aus und wieder ein zu schalten. Bei mir hat es meist zwei Starts gebraucht bis alle readings angelegt waren.
Hatte ich schon zig mal versucht, leider erfolglos
Gibt es denn irgendwo eine Erklärung, was die ganzen Attribute wie MapReading bedeuten ?
Zitat von: Klaus0815 am 01 November 2015, 19:37:26
Was bedeutet denn "Autocreate ist noch fehlerhaft " ?
Genau das, was Du beschreibst ;)
Legst Du Mappings manuell an, wird alles sauber funktionieren.
So in etwa:
attr MYSENSOR_1 mapReading_humidity 0 humidity
attr MYSENSOR_1 mapReading_temperature 1 temperature
attr MYSENSOR_1 mapReading_motion 2 tripped
Hallo Hexenmeister, jooo ist denn schon Weihnachten ;D
jupp genau so, hatte ich mir das vorgestellt ;)
gepatchte Version eingespielt, Sensor neu gestartet, damit die Sketchversion übermitelt wird (Bild: fhem-1)
FHEM neu gestartet (Bild: fhem-2)
Supi großes Dankeschön
Hallo Hexenmeister, bin einen Schritt weiter, es funktioniert teilweise
Könntest Du ( oder auch gerne jemand anders die Zusammenhänge erklären ?
Beispiel:
attr MYSENSOR_1 mapReading_humidity 0 humidity
Wofür stehen die beiden "humidity" ?
Mysensors schickt ja nur ein "HUM" ?
2015.11.01 20:59:54.419 5: MYSENSORS Read: Rx: fr=101 ci=000 c=001(C_SET ) st=001(V_HUM ) ack=0 '44.7'
Würde sicher einigen ausser mir helfen, es etwas besser zu verstehen ?
Viele Grüße
Klaus
Wie Commandref schon sagt:
Zitatattr <name> mapReading_<reading> <childId> <readingtype> [<value>:<mappedvalue>]*
configures the reading-name for a given childId and sensortype
E.g.: attr xxx mapReading_aussentemperatur 123 temperature
Damit legt man fest, dass ein Reading mit einem bestimmten Namen angelegt und aktualisiert werden soll, falls ein Message mit der gegebenen ChildID ankommt und dieser ist dann als spezieller Typ (temperature, humidity etc.) zu interpretieren ist.
Intern wird humidity schon als V_HUM gemappt:
V_HUM => { type => "humidity" },
Gleich noch ne Frage, woher kommt "Motion" ?
(siehe Screenshot)
in der fhem.cfg steht nichts davon ?
define MYSENSOR_102 MYSENSORS_DEVICE 102
attr MYSENSOR_102 IODev MySensorsGatewayWerkstatt
attr MYSENSOR_102 mapReading_humidity 0 humidity
attr MYSENSOR_102 mapReading_temperature1 1 temperature
attr MYSENSOR_102 mapReading_tripped2 2 tripped
attr MYSENSOR_102 mode node
attr MYSENSOR_102 room mysensors
attr MYSENSOR_102 version 1.5
Zitat von: Klaus0815 am 01 November 2015, 21:17:33
Gleich noch ne Frage, woher kommt "Motion" ?
(siehe Screenshot)
in der fhem.cfg steht nichts davon ?
Keine Ahnung, normal sollte nur kommen, wenn entsprechendes Mapping definiert ist. Da diese Reading länger nicht aktualisiert wurde, als der Rest, denke ich, dass das ein Überrest eines anderes, altes Mappings sein wird.
Zitat von: Klaus0815 am 01 November 2015, 21:08:35
Hallo Hexenmeister, bin einen Schritt weiter, es funktioniert teilweise
Könntest Du ( oder auch gerne jemand anders die Zusammenhänge erklären ?
Beispiel:
attr MYSENSOR_1 mapReading_humidity 0 humidity
Wofür stehen die beiden "humidity" ?
Mysensors schickt ja nur ein "HUM" ?
2015.11.01 20:59:54.419 5: MYSENSORS Read: Rx: fr=101 ci=000 c=001(C_SET ) st=001(V_HUM ) ack=0 '44.7'
Würde sicher einigen ausser mir helfen, es etwas besser zu verstehen ?
Viele Grüße
Klaus
Hallo Alex,
ich arbeite mir Deiner aktuellen Version Multisensor, die ohne B habe ich als Sketch verwendet,Problem es legt immer das Batterie reading mit an. FHEM SEITIG HABE ICH das aktuelle UD geladen, es sollte die neuste Version MySensor sein ...oder.? Die GW Ver. Ist 1.5. Serial geht sehr gut ohne Abbruch, Lan -GW ist ein echtes Problem, habe beide Hardware - Versionen verbaut und getestet immer wieder Abbrüche, hast einen Tipp ?
Besten Dank im voraus für Deine tolle Arbeit
oh je, große Baustelle für mich :-)
was ich beim mapping nicht verstehe, wie man von V_HUM auf mapReading_humidity 0 kommt ?
- sorry , sehe gerade Du hast Deine Antwort editiert, jetzt wird's klar
Das mit dem Motion ist mir auch nicht wirklich klar, es gibt keinerlei Eintrag dazu in der fhem.cfg, gibt es noch andere Dateien wo das gespeichert wird ?
Viele Grüße
Klaus
Zitat von: Peter_64 am 01 November 2015, 21:25:38
ich arbeite mir Deiner aktuellen Version Multisensor, die ohne B habe ich als Sketch verwendet,Problem es legt immer das Batterie reading mit an. FHEM SEITIG HABE ICH das aktuelle UD geladen, es sollte die neuste Version MySensor sein ...oder.? Die GW Ver. Ist 1.5. Serial geht sehr gut ohne Abbruch, Lan -GW ist ein echtes Problem, habe beide Hardware - Versionen verbaut und getestet immer wieder Abbrüche, hast einen Tipp ?
Hm... kann so nichts dazu sagen, außer, dass bei mir kein Bat-Reading angelegt wird.
Was meinst Du mit 'UD'? Ich benutze auch Version 1.5 und habe auch Stabilitätsprobleme mit LAN-Gateway. Diese löse ich (halbwegs) auf die 'schmutzige' Art: Watchdog auf dem Gerät und Periodischer Reconnect in FHEM.
Ich will versuchen, ob WLAN-Gateway stabieler läuft, komme aber aus Zeitgründen derzeit nicht wirklich weiter.
Zitat von: hexenmeister am 01 November 2015, 21:42:00
Hm... kann so nichts dazu sagen, außer, dass bei mir kein Bat-Reading angelegt wird.
Was meinst Du mit 'UD'? Ich benutze auch Version 1.5 und habe auch Stabilitätsprobleme mit LAN-Gateway. Diese löse ich (halbwegs) auf die 'schmutzige' Art: Watchdog auf dem Gerät und Periodischer Reconnect in FHEM.
Ich will versuchen, ob WLAN-Gateway stabieler läuft, komme aber aus Zeitgründen derzeit nicht wirklich weiter.
UD, Sorry die 4 Mysensor Dateien habe ich über das aktuelle FHEM-Updade geladen, das müssten die aktuellen sein ...oder
Zitat von: Peter_64 am 01 November 2015, 21:45:50
UD, Sorry die 4 Mysensor Dateien habe ich über das aktuelle FHEM-Updade geladen, das müssten die aktuellen sein ...oder
Ja, wie genau äußert sich den Dein Problem? Log Meldungen?
Zitat von: fh555 am 01 November 2015, 20:30:37
jupp genau so, hatte ich mir das vorgestellt ;)
Habe pull request an ntruchsess geschickt. Wenn dies angenommen wird, kommt der Patch in das offizielle FHEM-Repo.
Zitat von: hexenmeister am 02 November 2015, 22:24:25
Habe pull request an ntruchsess geschickt. Wenn dies angenommen wird, kommt der Patch in das offizielle FHEM-Repo.
Das wäre supi, Danke noch einmal ;D
Zitat von: hexenmeister am 02 November 2015, 22:24:25
Habe pull request an ntruchsess geschickt. Wenn dies angenommen wird, kommt der Patch in das offizielle FHEM-Repo.
germerged und ins SVN commited (https://sourceforge.net/p/fhem/code/9820/)
Danke,
das macht die Übersicht von verschiedenen Softwareversionen (gerade, wenn man mehrere Test-Sketche am laufen hat) bei MySensors wesentlich leichter :-)
Gruß Jens
Nach dem heutigen (12.11.2015) Update bekomme ich einen Fehler in der fhem-Logdatei angezeigt und alle mysensors-Devices können nicht mehr geladen werden. Der Fehler lautet:
2015.11.12 09:51:17 1: reload: Error:Modul 10_MYSENSORS_DEVICE deactivated:
syntax error at ./FHEM/10_MYSENSORS_DEVICE.pm line 502, near ");"
2015.11.12 09:51:17 0: syntax error at ./FHEM/10_MYSENSORS_DEVICE.pm line 502, near ");"
Es fehlt in der Zeile 502 eine (zweite) schließende runde Klammer vor dem Semikolon. Die Programmzeile lautet korrekt:
Log3 ($name,4,"MYSENSORS_DEVICE $name: respond to config-request, node parentId = " . ($msg->{payload}));
Danke.
VG
Sven
seit dem heuigen Update, ist nicht nur das Problem was "SvenJust" schilderte, auch die Einträge der Softwareversion sind wieder verschwunden :-(
Gruß Jens
Ist mir ja ein bischen peinlich, dass ich grade ungetesteten Mist commited habe (ich hatte grade unterwegs ein bischen Zeit, aber keine Testhardware um einen Patch einzubauen, den mir der User 'wmr72' vor einer Weile geschickt hat):
Zitat von: SvenJust am 12 November 2015, 10:50:15Es fehlt in der Zeile 502 eine (zweite) schließende runde Klammer vor dem Semikolon.
Naja, eigentlich war es eine Klammer zu viel (https://sourceforge.net/p/fhem/code/9873/).
Vielen Dank jedenfalls für den prompten Hinweis.
Gruß,
Norbert
P.S. auf die neuen Readings 'SKETCH_NAME' und 'SKETCH_VERSION' kann der Patch aber keinen Einfluss gehabt haben. Wenn die Readings nach einem Neustart weg sind, dann hat das Speichern und Wiedereinlesen des States nicht geklappt, dann kommen die Werte erst nach einem Sensor-reset wieder.
Hallo ntruchsess und hexenmeister,
also ich habe den Sensor jetzt noch einmal aufgesucht, aufgeschraubt, reset ausgelöst.
Dann wieder wieder zurück zum Rechner und die neuen Readings 'SKETCH_NAME' und 'SKETCH_VERSION' sind wieder aktualiesiert wurden.
Daraufhin habe ich ins log geschaut und da war der Eintrag enthalten sowie der vom 01.11.2015 (als ich die geänderte Version getestet hatte). Also schein es erst einmal auch richtig abzuspeichern, nur mit den einlesen nach "längerer Zeit" scheint es nicht mehr zu funktionieren. :-\
Gruß Jens
Zitat von: fh555 am 12 November 2015, 22:38:43
Daraufhin habe ich ins log geschaut und da war der Eintrag enthalten sowie der vom 01.11.2015 (als ich die geänderte Version getestet hatte). Also schein es erst einmal auch richtig abzuspeichern, nur mit den einlesen nach "längerer Zeit" scheint es nicht mehr zu funktionieren. :-\
Ich kann leider wenig dazu sagen, das ist ein generelles Mechanismus von FHEM (hat nicht direkt mit dem MS-Modul zu tun). Mir ist leider schleierhaft, warum das nicht funktioniert, vor allen nach 'längerer Zeit', ein Verfallsdatum gibt es meines Wissens nicht.
Gut, also weitergetestet.
1.
FHEM Server gestoppt, aus den LOG den eben generierten Eintrag gelöscht, also nur noch den vom 01.11. stehen gelassen, dann FHEM Server wieder gestartet. Readings hat den Wert noch von eben inkl. der Uhrzeit.
Woher?
2.
FHEM Server runtergefahren und Raspi neu gestartet
Readings immernoch den Wert von eben inkl. der Uhrzeit
SKETCH_NAME Feuchte-BC547/BAT 2015-11-12 22:26:59
SKETCH_VERSION 2.5.C 2015-11-12 22:26:59
batterylevel 100 2015-11-12 22:58:46
brightness1 886 2015-11-12 22:58:46
parentId 0 2015-11-12 22:26:57
Wo holt er die Werte her? Wie schon gesagt, im Log vom Sensor, steht nur noch der Eintrag vom 01.11.2015
Jetzt verstehe ich, was du da machst ;D
Nene, Log hat damit nichts zu tun. Die aktuellen (letzten) Werte stehen in der State-Datei: fhem.save
Also fehlt dort dann irgendwann der Eintrag.
Aber wann?
Das ist doch Mist, wenn man das nicht Nachvollziehen kann, wann der Eintrag aus der "fhem.save" verschwindet und warum.
Dort stehen nur die Befehle zum Setzen der Readings-Werte. Also nur die Abbildung des letzten Standes. Irgendwann konnte der Wert nicht gesetzt werden, z.B. weil der Modul nicht geladen war (das aktuelle Klammerproblem). Danach wurde der Abbild ohne diesen Wert geschrieben.
naja, dann würde es ja funktionieren und wenn es "ntruchsess" durch das Klammerproblem nicht aus den Tritt gebracht hätte, wären wir auf das Problem evtl. gar nicht aufmerksam geworden (ich wollte nicht so Hart zu ntruchsess sein ::) )
Also wenn das Modul nicht sauber geladen wird und die Sensoren dann wieder mit gefixten Modul übtragen, werden die alten Werte gelöscht. Das ist aber trotzdem Mist.
Überlege mal, wenn du 10 - 20 verbaute Sensoren hast und dir die Arbeit machst, noch einmal alle aufzusuchen, zu öffnen um ein reset auszulösen, dann wieder zusammenbauen und dann kommt irgendwann ein Update, welches fehlerhaft ist und dann sind alle Werte weg, das ist schon ärgerlich :-\ oder etwa nicht?
Nun ja, wenn das Device nicht da ist, kann auch kein Reading gesetzt werden. FHEM verhält sich schon korrekt. Und Fehler passieren nun mal.
MySensor-Devices können remote restartet werden, dafür muss allerdings ein passender Bootloader drauf. Gewöhnliche Pro Minis gehen dabei in eine unendliche ResetSchleife.
Mache doch einfach ein automatisches Backup deiner StateFile, dann kannst Du bei Bedarf die Werte rausholen und über die Console setzen lassen.
Z.B. so:
define backupCfg notify global:SAVE {\
my $now = TimeNow();; $now =~ s/ /_/g;; $now =~ s/:/-/g;; \
`cp $attr{global}{configfile} ./savedir/$now.fhem.cfg`;;\
`cp $attr{global}{statefile} ./savedir/$now.fhem.state`;;\
}
Damit bei einem Abstürz möglichst wenig verloren geht, kann man StateFile regelmäßig sichern:
define saveState at +*00:10:00 {WriteStatefile()}
das Verhalten, dass Readings verschwinden, wenn sie beim Laden der fhem.save nicht übernommen werden können ist jedenfalls nicht MySensors-spezifisch, das kann prinzipiell mit jedem anderen Device auch passieren.
Finde ich auch nicht so doll - aber wenn man das Ändern wollte, müsste man den fhem-eigenen State-saving/-restore Mechanismus dahingehend überarbeiten - im MYSENSORS_DEVICE selbst kann man daran nicht viel ändern.
Hallo hexenmeister,
ich habe deine 2 Backupscripte mal ausprobiert, aber irgendwie funktioniert das nicht.
Da die fhem.cfg in /opt/fhem liegt, habe ich hier auch den Ordner savedir mal testweise angelegt und die Rechte gesetzt.
define backupCfg notify global:SAVE {\
my $now = TimeNow();; $now =~ s/ /_/g;; $now =~ s/:/-/g;; \
`cp $attr{global}{configfile} ./savedir/$now.fhem.cfg`;;\
`cp $attr{global}{statefile} ./savedir/$now.fhem.state`;;\
}
Das saveState wird ausgeführt aber es passiert weiter nichts.
define saveState at +*00:10:00 {WriteStatefile()}
Muss das dann nicht heißen:
define saveState at +*00:10:00 {backupCfg()}
Ich nehme alles zurück, wie von Geisterhand funktioniert es jetzt ;D
Zitat von: fh555 am 13 November 2015, 19:11:23
Ich nehme alles zurück, wie von Geisterhand funktioniert es jetzt ;D
Klar funktioniert das, sind ja gar nicht von mir, habe selbst mal abgeguckt ;D
Zum Verständnis: im ersten Script werden Kopien der Dateien durch Aufrufe ans System erstellt (und nach dem Erstelldatum benannt). Vorsicht, Falle: da keine Dateien gelöscht werden, kann man schon die Karte vollschreiben, und falls das root-Partition ist, dann wird sich das System mit großer Sicherheit aufhängen.
Das zweite Script hat mitdem ersten nichts direkt zu tun, es bewirkt, dass State zwangsweise alle 10 Minuten geschrieben wird (ansonsten wird FHEM nur beim Herunterfahren speichern).
Zitat von: hexenmeister am 13 November 2015, 20:00:37
Vorsicht, Falle: da keine Dateien gelöscht werden, kann man schon die Karte vollschreiben, und falls das root-Partition ist, dann wird sich das System mit großer Sicherheit aufhängen.
Ja habe ich schon mitbekommen und habe das Intervall auf 1H geändert.
Also speichert das 1. Script immer, wenn ein Speichervorgang von FHEM ausgelöst wird und das 2. zwingt FHEM per Zeitintervall dazu.
Richtig verstanden ???
Zitat von: fh555 am 13 November 2015, 21:18:48
Also speichert das 1. Script immer, wenn ein Speichervorgang von FHEM ausgelöst wird und das 2. zwingt FHEM per Zeitintervall dazu.
Richtig verstanden ???
Nee, so schlimm auch nicht. Script 2 ruft direkt eine interne Routine auf, dabei wird kein Ereignis ausgelöst. Also nur beim 'richtigen' Speichern wird kopiert.
Ok, alles klar ;D
Hi,
ich bin neu hier. Ich finde das wirklich Spitze was Ihr hier macht. Bin über Arduino zu dem Thema gekommen.
Ich habe inzwischen einige Sensoren gemacht, bekomme aber den Dimmer beim DimmableLEDActuator.ino nicht zum Laufen.
Ich wollte eine Kombnation von Licht ein/aus und Dimmer machen, kriegs nicht hin.
Licht ein /aus geht, beim Dimmer steh ich auf dem Schlauch. Hat denn schon einer von Euch das gemacht?
Ich wäre für die Hilfe dankbar.
mfg
Reinhold
Da die forumseigene Glaskugel kaput ist, wird dir leider niemand helfen können ;)
Es kann ein Problem mit der Hardware, mit der Firmware, mit der FHEM-Definition sein...
Wir wissen ja nicht, was genau Du gemacht hast und was genau nicht geht.
Danke für deine Antwort. Modul funktioniert, Licht kann aus und eingeschaltet werden. Ich weiß leider nicht wie ich bei FHEM den Dimmer einrichten muss, bzw ich den Dimmer mit Licht ein/aus kombinieren muss.
mfg
Reinhold
Jetzt verstehe ich das Problem. Leider habe ich noch keinen Dimmer gebaut.
Aus der Doku wurde ich für diesen Fall auch nicht ganz schlau. Evtl. kann an eine Liste der DimmWerte erstellen:
attr MYSENSOR_XYZ setReading_level 0,10,20,30,40,50,60,70,80,90,100
Kann (mangels Hardware) nicht ausprobieren, ob das funktioniert. Elegant ist es in jedem Fall nicht.
Bestimmt kann Norbert (@ntruchsess) etwas mehr Licht in die (gedimmte) Dunkelheit bringen ;D
habe folgendes Gerät gerade testweise 'konfiguriert'. Werte Setzen kann ich, nur Hardware habe ich immer noch nicht ;) Probiere mal aus.
define MYSENSOR_127 MYSENSORS_DEVICE 127
attr MYSENSOR_127 IODev mysensors
attr MYSENSOR_127 mapReading_dimmer 1 percentage
attr MYSENSOR_127 mapReading_switch 1 status
attr MYSENSOR_127 setCommands on:switch:on off:switch:off
attr MYSENSOR_127 setReading_dimmer 0,10,20,30,40,50,60,70,80,90,100
attr MYSENSOR_127 setReading_switch on,off
Hi,
danke für die Info.
Ich weiß inzwischen, dass es nicht funktioniert ... aber ich teste weiter.
mfg
Reinhold
Hallo dd_bauer,
vielleicht solltest Du doch genauer beschreiben, was Du bisher gamacht hast.
Ich habe gerade den MySensor Sketch "DimmableLEDActuator" auf einen Arduino geflashed, lediglich die Adresse habe ich festgelegt.
Der Sensor taucht in fhem direkt auf und ist vollständig bedienbar, auch ein Slider wird automatisch angelegt um den Dimmer zu bedienen.
- Welche MySensors Version nimmst Du ? 1.4 / 1.5
- ist fhem aktualisiert?
Ich frage, weil es hier in naher Vergangenheit Änderungen gegeben hat, zB beim Dimmer heißt es jetzt percentage statt (ich glaube) level.
So sieht es in der fhem.cfg aus, nachdem der Sensor angelegt wurde:
define MYSENSOR_25 MYSENSORS_DEVICE 25
attr MYSENSOR_25 IODev MySensorsGateway
attr MYSENSOR_25 mapReading_percentage 0 percentage
attr MYSENSOR_25 mapReading_power 0 power
attr MYSENSOR_25 mapReading_status 0 status
attr MYSENSOR_25 setReading_percentage slider,0,1,100
attr MYSENSOR_25 setReading_power 1
attr MYSENSOR_25 setReading_status on,off
Dann lass mal hören...
Hallo Sany
auf die Power und Percentage bin ich nicht gekommen. Ich habe die MySensors Version 1.5 und Fhem mit Änderung der Zeile 502 in "10_Mysensors_devices.pm" vor 2 Tagen aktualisiert.
Dein Ding funktioniert so. Danke.
mfg
Reinhold
Noch mal zum verdeutlichen: der Auszug aus der fhem.cfg zeigt das, was automatisch beim ersten Start des Sensors angelegt wurde. Ich habe nichts von Hand eingegeben.
Wenn es nicht zu viel ist dann kannst Du ja den Sensor noch mal komplett aus fhem löschen (dann SAVE nicht vergessen) und dann einmal neu starten. Dann kannst Du genau sehen, was angelegt wird. Sollte etwas fehlen kann es wohl helfen, den Sensor zu resetten. fhem kann dann fehlende Einträge ergänzen (das stand hier schon mal so ähnlich, ich kann es nicht bestätigen)
Viel Erfolg!
Hallo Sany
du hast Recht. Ich hatte den Sensor vor dem Update angelegt. Nach dem Löschen liest FHEM die Werte ein.
Hi,
hat einer von euch schon versucht, den AirQualitySensor-Sketch, in Fhem einzubinden ? Ich verwende als Sensor den MQ-2. Wenn ich das Gateway, den Sensor einbinden lassen, erstellt das autoscript folgendes.
define MYSENSOR_111 MYSENSORS_DEVICE 111
attr MYSENSOR_11 IODev gateway
attr MYSENSOR_PIRWoh mapReading_level 1 level
attr MYSENSOR_PIRWoh mode node
attr MYSENSOR_PIRWoh version 1.5
Wie ihr seht bindet das Script nur Level ein. Es müsste aber :
#define GAS_LPG (0)
#define GAS_CO (1)
#define GAS_SMOKE (2)
einbinden. Und dieses in als Graph. (LPGCurve ,COCurve[3] , SmokeCurve[3]).
Hat wer eine Idee wie ich die Config erweitern muss ? Bzw. müsste ich auch was am MYSENSOR-Modul ändern ?
Vielen Dank für die Hilfe
Zitat von: neonet am 17 November 2015, 11:16:22
Hi,
hat einer von euch schon versucht, den AirQualitySensor-Sketch, in Fhem einzubinden ? Ich verwende als Sensor den MQ-2. Wenn ich das Gateway, den Sensor einbinden lassen, erstellt das autoscript folgendes.
define MYSENSOR_111 MYSENSORS_DEVICE 111
attr MYSENSOR_11 IODev gateway
attr MYSENSOR_PIRWoh mapReading_level 1 level
attr MYSENSOR_PIRWoh mode node
attr MYSENSOR_PIRWoh version 1.5
Wie ihr seht bindet das Script nur Level ein. Es müsste aber :
#define GAS_LPG (0)
#define GAS_CO (1)
#define GAS_SMOKE (2)
einbinden. Und dieses in als Graph. (LPGCurve ,COCurve[3] , SmokeCurve[3]).
Hat wer eine Idee wie ich die Config erweitern muss ? Bzw. müsste ich auch was am MYSENSOR-Modul ändern ?
Vielen Dank für die Hilfe
Ich muss dich enttäuschen es wird nur folgendes gesendet:
MyMessage msg(CHILD_ID_MQ, V_LEVEL);https://github.com/mysensors/Arduino/blob/master/libraries/MySensors/examples/AirQualitySensor/AirQualitySensor.ino
Den ganzen AirQualitySensor habe ich noch nicht 100% verstanden :D fh555 (Robin) hat es hier mit einem Display gelöst: http://blog.moneybag.de/gassensor-mq-7-mit-lcd-display-und-arduino-nano/ -es soll wohl tatsächlich immer nur eine Zahl entstehen. Die eine Zahl ist wohl irgendwie ein Produkt aus den ganzen einzelnen Faktoren. Leider kann man aber nicht differenzieren zwischen CO, Rauch und LPG... ausser ich verstehe es falsch ;)
Hallo!
Zitat von: Hauswart am 17 November 2015, 12:18:21
Ich muss dich enttäuschen es wird nur folgendes gesendet:
MyMessage msg(CHILD_ID_MQ, V_LEVEL);
https://github.com/mysensors/Arduino/blob/master/libraries/MySensors/examples/AirQualitySensor/AirQualitySensor.ino
Den ganzen AirQualitySensor habe ich noch nicht 100% verstanden :D fh555 (Robin) hat es hier mit einem Display gelöst: http://blog.moneybag.de/gassensor-mq-7-mit-lcd-display-und-arduino-nano/ -es soll wohl tatsächlich immer nur eine Zahl entstehen. Die eine Zahl ist wohl irgendwie ein Produkt aus den ganzen einzelnen Faktoren. Leider kann man aber nicht differenzieren zwischen CO, Rauch und LPG... ausser ich verstehe es falsch ;)
In dem mysensors Sketch wird nur der GAS_CO Wert übermittelt. Die weiteren Werte werden nur auf die serielle Console geschrieben, es findet (soweit ich sehe) keine Berechnung zu einem Wert statt.
Der Sourcecode für mysensors stammt von http://sandboxelectronics.com/?p=165. Hier erfolgt die Ausgabe der Einzelwerte.
VG
Sven
Zitat von: SvenJust am 17 November 2015, 13:24:33
Hallo!
In dem mysensors Sketch wird nur der GAS_CO Wert übermittelt. Die weiteren Werte werden nur auf die serielle Console geschrieben, es findet (soweit ich sehe) keine Berechnung zu einem Wert statt.
Der Sourcecode für mysensors stammt von http://sandboxelectronics.com/?p=165. Hier erfolgt die Ausgabe der Einzelwerte.
Eigentlich hätte ein kurzer Blick in den Code mir ausreichen müssen :P
uint16_t valMQ = MQGetGasPercentage(MQRead(MQ_SENSOR_ANALOG_PIN)/Ro,GAS_CO);gw.send(msg.set((int)ceil(valMQ))); 8)
Eigentlich könnte man den Sketch auch umschreiben, so dass alle Werte übertragen werden können....
Ich versuche es gleich mal aber das ist dann mehr Try and Error. Wenn es einer besser kann , wäre es natürlich vamos :-).
Probiere mal meinen Sketch: https://github.com/Kolbi/Arduino/blob/master/libraries/MySensors/examples/AirQualitySensor/AirQualitySensor.ino
Edit: Warte noch kurz!
Edit2: Jetzt aber :)
AirQualitySensor:103: error: 'CHILD_ID_LPG' was not declared in this scope
AirQualitySensor:104: error: 'CHILD_ID_SMOKE' was not declared in this scope
Warum kann man nicht für alle drei
#define CHILD_ID_MQ nehmen ?
Nachtrag:
ich habe jetzt als CHILD_ID für alle drei Werte CHILD_ID_MQ genommen
Das kommt dann mit dem auto-script:
define MYSENSOR_102 MYSENSORS_DEVICE 102
attr MYSENSOR_102 IODev gateway
attr MYSENSOR_102 mapReading_level 0 level
attr MYSENSOR_102 mapReading_unitprefix 0 unitprefix
attr MYSENSOR_102 mapReading_value1 0 value1
attr MYSENSOR_102 mapReading_value2 0 value2
attr MYSENSOR_102 mapReading_value3 0 value3
attr MYSENSOR_102 mapReading_value4 0 value4
attr MYSENSOR_102 mapReading_value5 0 value5
attr MYSENSOR_102 mode node
attr MYSENSOR_102 version 1.5
Zitat von: neonet am 17 November 2015, 16:34:31
AirQualitySensor:103: error: 'CHILD_ID_LPG' was not declared in this scope
AirQualitySensor:104: error: 'CHILD_ID_SMOKE' was not declared in this scope
Warum kann man nicht für alle drei
#define CHILD_ID_MQ nehmen ?
Haben den Fehler korrigiert. Du wirst ansonsten mit dem Daten übertragen wahrscheinlich Probleme bekommen: http://www.mysensors.org/download/sensor_api_15
Edit: Habe noch einmal etwas angepasst.
Sollte so hoffentlich gehen:
https://github.com/Kolbi/Arduino/blob/9edc228b1c8b3f63968f0a731d9341dea0aa3b40/libraries/MySensors/examples/AirQualitySensor/AirQualitySensor.ino
Ansonsten:
https://github.com/Kolbi/Arduino/blob/777f0d28f3914b5f9e0c37a7089fb005d391227a/libraries/MySensors/examples/AirQualitySensor/AirQualitySensor.ino
Leider bei beiden immer noch ein Fehler:
AirQualitySensor:92: error: 'CHILD_ID_LPG' was not declared in this scope
AirQualitySensor.ino: In function 'void setup()':
AirQualitySensor:107: error: 'CHILD_ID_LPG' was not declared in this scope
'CHILD_ID_LPG' was not declared in this scope
Zitat von: neonet am 18 November 2015, 12:37:57
Leider bei beiden immer noch ein Fehler:
AirQualitySensor:92: error: 'CHILD_ID_LPG' was not declared in this scope
AirQualitySensor.ino: In function 'void setup()':
AirQualitySensor:107: error: 'CHILD_ID_LPG' was not declared in this scope
'CHILD_ID_LPG' was not declared in this scope
Jetzt sollte es aber: https://github.com/Kolbi/Arduino/blob/master/libraries/MySensors/examples/AirQualitySensor/AirQualitySensor.ino
Hatte mich vertippt LPQ anstatt LPG :P
Schaue es mir gleich an.
Jetzt funktioniert es aber Fhem empfängt keine Werte bzw. immer nur 0 für jedes Level. Ich teste gleich mal nur den Sensor ohne MySensor.
Zitat von: neonet am 19 November 2015, 13:14:10
Jetzt funktioniert es aber Fhem empfängt keine Werte bzw. immer nur 0 für jedes Level. Ich teste gleich mal nur den Sensor ohne MySensor.
Falls du den Sensor mal Seriell auslesen könntest, wäre es super :) Dann wissen wir, ob die Werte an sich falsch sind, oder ob FHEM die falschen Werte bekommt.
Zitat von: Hauswart am 19 November 2015, 13:28:38
Falls du den Sensor mal Seriell auslesen könntest, wäre es super :) Dann wissen wir, ob die Werte an sich falsch sind, oder ob FHEM die falschen Werte bekommt.
Am Besten im Sensor das Debugging einschalten, dann gibt es die Ausgaben auf die serielle Console, auch die Sendeinformationen. Dazu in der Datei MyConfig.h das
#define DEBUG nicht auskommentieren, also Kommentarzeichen entfernen.
VG
Sven
Juchu,
mein 1. Sensor (DHT22) läuft mit dem ESP8266-Gateway und zeigt mir nachvollziehbare Daten an ;D ;D ;D.
Danke den fleißigen Vordenkern. Ohne euch hätte ich es nicht geschafft! :-*
Eine Grundsatzfrage treibt mich aber noch um: am Anfang des nun doch etwas längeren Treads wird noch viel über MQTT gesprochen. In wie weit ist das überhaupt für diese Anwendung (MySensors) noch notwendig bzw. sinnvoll?
LG
Holger
Zitat von: Omega am 19 November 2015, 15:12:26
Eine Grundsatzfrage treibt mich aber noch um: am Anfang des nun doch etwas längeren Treads wird noch viel über MQTT gesprochen. In wie weit ist das überhaupt für diese Anwendung (MySensors) noch notwendig bzw. sinnvoll?
MQTT war zu Beginn der Integration von mysensors in ein FHEM System notwendig, da es eine Möglichkeit darstellt die Daten nach FHEM zu übertragen. Seit es die mysensors-Module in FHEM gibt, muss das MQTT Gateway nicht mehr verwendet werden. Damit ist eine Komponente (MQTT) weniger notwendig.
BTW: Ich nutze mysensors seit etwa einem halben Jahr, um den Luftdruck zu messen und an FHEM zu übertragen. Seit 5 Tagen ist eine Temperaturmessung mit vier 1Wire Temperatursensoren dazu gekommen. Als Gateway nutze ich ein EthernetGateway und alles ist absolut stabil, viel stabiler als WLAN-Strecken, die ich leider zur Heizung hin nutzen muss. Über die WLAN-Strecke nutze ich wiederrum MQTT, um die Daten der Heizung nach FHEM zu bekommen. Die MQTT Verbindung ist auch problemlos.
VG
Sven
Danke. Wieder ein bisschen schlauer :)
@SvenJust,
Eine Frage zu Deinem EthernetGateway, welche Hardware nutzt Du, und mit welcher Sketch – Version. Ich hab Probleme mit EthernetGateway, beide Versionen W5100 und ENC28J60 getestet mit UNU und Schild sowie NANO mit dem MINI W5100 Schild . Arduino 1.6.4, MySensor 1.5, aktuelle Module FHEM. Serial – Modul läuft stabil ohne Abbruch. EthernetGateway ENC28J60 würde stabil laufen, geht aber immer wieder auf disconnect. EthernetGateway W5100 startet auf der Arduino Konsole korrekt, aber keine Daten zu FHEM. Für das Sketch W5100 wurde SOFTSPI in der MyConfig.h aktiviert und die IP geändert, muss man da noch mehr ändern ?.
Zitat von: Peter_64 am 20 November 2015, 09:15:21
@SvenJust,
Eine Frage zu Deinem EthernetGateway, welche Hardware nutzt Du, und mit welcher Sketch – Version. Ich hab Probleme mit EthernetGateway, beide Versionen W5100 und ENC28J60 getestet mit UNU und Schild sowie NANO mit dem MINI W5100 Schild . Arduino 1.6.4, MySensor 1.5, aktuelle Module FHEM. Serial – Modul läuft stabil ohne Abbruch. EthernetGateway ENC28J60 würde stabil laufen, geht aber immer wieder auf disconnect. EthernetGateway W5100 startet auf der Arduino Konsole korrekt, aber keine Daten zu FHEM. Für das Sketch W5100 wurde SOFTSPI in der MyConfig.h aktiviert und die IP geändert, muss man da noch mehr ändern ?.
Hallo,
ich habe mir gerade den meinen Sketch angesehen, ich nutze bei der Hardware einen Arduino Nano mit dem W5100 Modul und NRF24L01+. MySensors 1.4.1, Arduino 2:1.0.5 unter Linux, SoftSPI, IP angepasst, keine weiteren Änderungen; aktuelle FHEM Module und wie geschrieben alles ist stabil.
VG
Sven
Zitat von: neonet am 19 November 2015, 13:14:10
Jetzt funktioniert es aber Fhem empfängt keine Werte bzw. immer nur 0 für jedes Level. Ich teste gleich mal nur den Sensor ohne MySensor.
Hast du schon Neuigkeiten? :) Wenn der Patch funktioniert, dann würde ich ihn in die offizielle MySensors Repo einchecken.
Zitat von: SvenJust am 20 November 2015, 14:31:38
Hallo Sven,
dank Dir für die Info
ich habe mir gerade den meinen Sketch angesehen, ich nutze bei der Hardware einen Arduino Nano mit dem W5100 Modul und NRF24L01+. MySensors 1.4.1, Arduino 2:1.0.5 unter Linux, SoftSPI, IP angepasst, keine weiteren Änderungen; aktuelle FHEM Module und wie geschrieben alles ist stabil.
VG
Sven
Hallo,
ich benutze als Gateway-Sketch die MyEsp8266Gateway.ino von Hexenmeister. Funktioniert auch einwandfrei. Allerdings würde ich gerne eine statische IP vergeben (über den Sketch und nicht über den Router unter Zuhilfenahme der MAC-Adresse). Nur ist mir leider nicht klar, wo und wie ich dabei eingreifen müsste).
Mit den Variablen (eingefügt im Include MySecret.h)
// Enable MY_IP_ADDRESS here if you want a static ip address (no DHCP)
#define MY_IP_ADDRESS 192,168,0,221
// If using static ip you need to define Gateway and Subnet address as well
#define MY_IP_GATEWAY_ADDRESS 192,168,0,1
#define MY_IP_SUBNET_ADDRESS 255,255,0,0
habe ich es schon probiert, es bleibt aber bei der per DHCP zugewiesenen IP.
Hat das schon einer gelöst?
Zitat von: SvenJust am 19 November 2015, 13:41:04
Am Besten im Sensor das Debugging einschalten, dann gibt es die Ausgaben auf die serielle Console, auch die Sendeinformationen. Dazu in der Datei MyConfig.h das #define DEBUG nicht auskommentieren, also Kommentarzeichen entfernen.
VG
Sven
Hier mal ein Auszug aus der Konsole
LPG:221ppm CO:1440ppm SMOKE:119ppm
send: 102-102-0-0 s=0,c=1,t=37,pt=2,l=2,sg=0,st=ok:-17632
send: 102-102-0-0 s=1,c=1,t=37,pt=2,l=2,sg=0,st=ok:1813
send: 102-102-0-0 s=2,c=1,t=37,pt=2,l=2,sg=0,st=ok:3593
0
LPG:0ppm CO:0ppm SMOKE:0ppm
send: 102-102-0-0 s=0,c=1,t=37,pt=2,l=2,sg=0,st=ok:0
send: 102-102-0-0 s=1,c=1,t=37,pt=2,l=2,sg=0,st=ok:0
send: 102-102-0-0 s=2,c=1,t=37,pt=2,l=2,sg=0,st=ok:0
0
LPG:29460ppm CO:0ppm SMOKE:480ppm
send: 102-102-0-0 s=1,c=1,t=37,pt=2,l=2,sg=0,st=ok:-31198
send: 102-102-0-0 s=2,c=1,t=37,pt=2,l=2,sg=0,st=ok:2112
0
LPG:0ppm CO:0ppm SMOKE:0ppm
send: 102-102-0-0 s=1,c=1,t=37,pt=2,l=2,sg=0,st=fail:0
send: 102-102-0-0 s=2,c=1,t=37,pt=2,l=2,sg=0,st=fail:0
0
LPG:1ppm CO:5ppm SMOKE:4ppm
send: 102-102-0-0 s=0,c=1,t=37,pt=2,l=2,sg=0,st=ok:9
send: 102-102-0-0 s=1,c=1,t=37,pt=2,l=2,sg=0,st=ok:1
send: 102-102-0-0 s=2,c=1,t=37,pt=2,l=2,sg=0,st=ok:5
Zitat von: Omega am 20 November 2015, 16:18:59
ich benutze als Gateway-Sketch die MyEsp8266Gateway.ino von Hexenmeister. Funktioniert auch einwandfrei. Allerdings würde ich gerne eine statische IP vergeben (über den Sketch und nicht über den Router unter Zuhilfenahme der MAC-Adresse). Nur ist mir leider nicht klar, wo und wie ich dabei eingreifen müsste).
Der Sketch ist ja von mir nur geringfügig aufgebohrt worden. ;)
Zitat von: Omega am 20 November 2015, 16:18:59
Mit den Variablen (eingefügt im Include MySecret.h)
// Enable MY_IP_ADDRESS here if you want a static ip address (no DHCP)
#define MY_IP_ADDRESS 192,168,0,221
// If using static ip you need to define Gateway and Subnet address as well
#define MY_IP_GATEWAY_ADDRESS 192,168,0,1
#define MY_IP_SUBNET_ADDRESS 255,255,0,0
habe ich es schon probiert, es bleibt aber bei der per DHCP zugewiesenen IP.
Naja, diese müssen ja auch irgendwo irgendeine Bedeutung haben, um zu funktionieren ;)
Internet ist Dein Freund: https://www.arduino.cc/en/Reference/WiFiConfig
ZitatWiFi.config()
Description
WiFi.config() allows you to configure a static IP address as well as change the DNS, gateway, and subnet addresses on the WiFi shield.
Unlike WiFi.begin() which automatically configures the WiFi shield to use DHCP, WiFi.config() allows you to manually set the network address of the shield.
Calling WiFi.config() before WiFi.begin() forces begin() to configure the WiFi shield with the network addresses specified in config().
You can call WiFi.config() after WiFi.begin(), but the shield will initialize with begin() in the default DHCP mode. Once the config() method is called, it will change the network address as requested.
Syntax
WiFi.config(ip);
WiFi.config(ip, dns);
WiFi.config(ip, dns, gateway);
WiFi.config(ip, dns, gateway, subnet);
Scheinbar kenn die ESP-Lib nur eine davon:
void config(IPAddress local_ip, IPAddress gateway, IPAddress subnet);Probiere meine letzte Version aus GitHub und setze USE_STATIC_IP auf 1
Zitat von: neonet am 20 November 2015, 19:45:52
Hier mal ein Auszug aus der Konsole
LPG:221ppm CO:1440ppm SMOKE:119ppm
send: 102-102-0-0 s=0,c=1,t=37,pt=2,l=2,sg=0,st=ok:-17632
send: 102-102-0-0 s=1,c=1,t=37,pt=2,l=2,sg=0,st=ok:1813
send: 102-102-0-0 s=2,c=1,t=37,pt=2,l=2,sg=0,st=ok:3593
0
LPG:0ppm CO:0ppm SMOKE:0ppm
send: 102-102-0-0 s=0,c=1,t=37,pt=2,l=2,sg=0,st=ok:0
send: 102-102-0-0 s=1,c=1,t=37,pt=2,l=2,sg=0,st=ok:0
send: 102-102-0-0 s=2,c=1,t=37,pt=2,l=2,sg=0,st=ok:0
0
LPG:29460ppm CO:0ppm SMOKE:480ppm
send: 102-102-0-0 s=1,c=1,t=37,pt=2,l=2,sg=0,st=ok:-31198
send: 102-102-0-0 s=2,c=1,t=37,pt=2,l=2,sg=0,st=ok:2112
0
LPG:0ppm CO:0ppm SMOKE:0ppm
send: 102-102-0-0 s=1,c=1,t=37,pt=2,l=2,sg=0,st=fail:0
send: 102-102-0-0 s=2,c=1,t=37,pt=2,l=2,sg=0,st=fail:0
0
LPG:1ppm CO:5ppm SMOKE:4ppm
send: 102-102-0-0 s=0,c=1,t=37,pt=2,l=2,sg=0,st=ok:9
send: 102-102-0-0 s=1,c=1,t=37,pt=2,l=2,sg=0,st=ok:1
send: 102-102-0-0 s=2,c=1,t=37,pt=2,l=2,sg=0,st=ok:5
Das MySensors-Device sendet Pakete mit Daten, erkennbar an dem
ok in der Zeile
send: 102-102-0-0 s=0,c=1,t=37,pt=2,l=2,sg=0,st=ok:9Vermutlich werden die eingehenden Pakete in Fhem nicht den Readings zugeordnet. Voraussetzung ist, dass das MySensors-Gateway in Fhem funktioniert.
Die folgenden Mappings ordnen die eingehenden Werte den Reading
val0, val1, val2 zu. Die Namen der Readings sind beliebig.
attr <DEVICENAME> mapReading_val0 0 level
attr <DEVICENAME> mapReading_val1 1 level
attr <DEVICENAME> mapReading_val2 2 levelErläuterungen gibt es in der englischen Commandref zu den MySensors-Modulen.
VG
Sven
@Hexenmeister: Danke, du hast mir die richtigen Stichwörter geliefert.
Um eine statische IP zu erhalten, sind folgende Modifikationen in dem Sketch MyEsp8266Gateway.ino notwendig:
Nach der Zeile ,,const char *pass = MY_WLAN_PASS; //"
kommen zunächst folgende Definitionen:
// Update these with values suitable for your network.
IPAddress ip(192,168,0,221); //Node static IP
IPAddress dns(192,168,0,1);
IPAddress gateway(192,168,0,1);
IPAddress subnet(255,255,255,0);
Danach ist nur noch der Aufruf von ,,WiFi.config(ip, dns, gateway, subnet);" notwendig nach der Zeile
,,WiFi.begin(ssid, pass);"
(void)WiFi.begin(ssid, pass);
WiFi.config(ip, dns, gateway, subnet);
while (WiFi.status() != WL_CONNECTED)
Ich benutze die IDE 1.6.5
In älteren Versionen werden wohl nur 3 Argumente übergeben (ip, gateway, subnet). Hier kann es daher zu Unterschieden kommen.
Zitat von: SvenJust am 20 November 2015, 21:23:35
Das MySensors-Device sendet Pakete mit Daten, erkennbar an dem ok in der Zeile send: 102-102-0-0 s=0,c=1,t=37,pt=2,l=2,sg=0,st=ok:9
Vermutlich werden die eingehenden Pakete in Fhem nicht den Readings zugeordnet. Voraussetzung ist, dass das MySensors-Gateway in Fhem funktioniert.
Die folgenden Mappings ordnen die eingehenden Werte den Reading val0, val1, val2 zu. Die Namen der Readings sind beliebig.
attr <DEVICENAME> mapReading_val0 0 level
attr <DEVICENAME> mapReading_val1 1 level
attr <DEVICENAME> mapReading_val2 2 level
Erläuterungen gibt es in der englischen Commandref zu den MySensors-Modulen.
VG
Sven
Die Readings kommen an, sind aber falsch. Als Beispiel:
LPG:221ppm CO:1440ppm SMOKE:119ppm
send: 102-102-0-0 s=0,c=1,t=37,pt=2,l=2,sg=0,st=ok:-17632
send: 102-102-0-0 s=1,c=1,t=37,pt=2,l=2,sg=0,st=ok:1813
send: 102-102-0-0 s=2,c=1,t=37,pt=2,l=2,sg=0,st=ok:3593
Er sendet nicht für SMOKE 119ppm sondern 3593. Das meinte ich mit Fehler.
Muss ich mir morgen oder am Montag mal anschauen. In FHEM kommen sie aber mittlerweile an? Auch wenn es die falschen Werte sind?
Hallo,
für alle die es noch interessiert...
DimmableLEDActuator läuft seit meinem letzten Post:
define WZ_dimmer MYSENSORS_DEVICE 104
attr WZ_dimmer IODev MS_gateway
attr WZ_dimmer group Licht
attr WZ_dimmer mapReading_percentage 0 percentage
attr WZ_dimmer mapReading_power 0 power
attr WZ_dimmer mapReading_status 0 status
attr WZ_dimmer mode node
attr WZ_dimmer room WZ
attr WZ_dimmer setReading_percentage slider,0,1,100
attr WZ_dimmer setReading_power 1
attr WZ_dimmer setReading_status on,off
attr WZ_dimmer stateFormat percentage
attr WZ_dimmer version 1.5
attr WZ_dimmer webCmd status:percentage
define WZ_dimmer_ico notify WZ_dimmer:percentage.* {\
my $pctwz = int(%EVTPART1/10)*10;;\
$pctwz = "00" if (!$pctwz);;\
fhem("attr WZ_dimmer devStateIcon .*:light_light_dim_$pctwz");;\
}
Hallo neonet
ZitatDie Readings kommen an, sind aber falsch. Als Beispiel:
LPG:221ppm CO:1440ppm SMOKE:119ppm
send: 102-102-0-0 s=0,c=1,t=37,pt=2,l=2,sg=0,st=ok:-17632
send: 102-102-0-0 s=1,c=1,t=37,pt=2,l=2,sg=0,st=ok:1813
send: 102-102-0-0 s=2,c=1,t=37,pt=2,l=2,sg=0,st=ok:3593
Er sendet nicht für SMOKE 119ppm sondern 3593. Das meinte ich mit Fehler.
verwendest Du den Sketch aus Post #564?
Ich habe mir den mal angeschaut und würde dort ein paar Änderungen vornehmen:
so steht er auf Github:
void loop()
{
uint16_t valMQ = MQGetGasPercentage(MQRead(MQ_SENSOR_ANALOG_PIN)/Ro,GAS_CO);
//Start Test
uint16_t valMQ2 = MQGetGasPercentage(MQRead(MQ_SENSOR_ANALOG_PIN)/Ro,GAS_LPG);
uint16_t valMQ3 = MQGetGasPercentage(MQRead(MQ_SENSOR_ANALOG_PIN)/Ro,GAS_SMOKE);
//Ende Test
Serial.println(val);
Serial.print("LPG:");
Serial.print(MQGetGasPercentage(MQRead(MQ_SENSOR_ANALOG_PIN)/Ro,GAS_LPG) );
Serial.print( "ppm" );
Serial.print(" ");
Serial.print("CO:");
Serial.print(MQGetGasPercentage(MQRead(MQ_SENSOR_ANALOG_PIN)/Ro,GAS_CO) );
Serial.print( "ppm" );
Serial.print(" ");
Serial.print("SMOKE:");
Serial.print(MQGetGasPercentage(MQRead(MQ_SENSOR_ANALOG_PIN)/Ro,GAS_SMOKE) );
Serial.print( "ppm" );
Serial.print("\n");
//Start Test
if (valMQ != lastMQ) {
gw.send(msg.set((int)ceil(valMQ)));
lastMQ = ceil(valMQ);
}
if (valMQ2 != lastMQ2) {
gw.send(msgLPG.set((int)ceil(valMQ2)));
lastMQ2 = ceil(valMQ2);
}
if (valMQ3 != lastMQ3) {
gw.send(msgSMOKE.set((int)ceil(valMQ3)));
lastMQ3 = ceil(valMQ3);
}
//Ende Test
gw.sleep(SLEEP_TIME); //sleep for: sleepTime
}Am Anfang der Loop wird der Sensor ausgelesen und die ermittelten Werte in variablen geschrieben. Diese sind als unsigned int deklariert, also nur positive Ganzzahlen.
Gleich danach werden sie auf der Konsole ausgegeben, aber hier werden die Sensoren nochmals gelesen. Das macht keinen Sinn, denn 2 mal Sensor auslesen bringt ziemlich sicher 2 verschiedene Werte. Also besser:
Serial.print("LPG:");
Serial.print(GAS_LPG);
Serial.print( "ppm" );
das druckt die den Inhalt der Variablen, die Du ja gerade mit dem Sensorwert gefüttert hast. Die anderen 2 Zeilen bitte entsprechend anpassen.
dann kommt der Sendeteil:
if (valMQ != lastMQ) {
gw.send(msg.set((int)ceil(valMQ)));
lastMQ = ceil(valMQ);
}
erste und letzte Zeile sorgen ja nur dafür, dass ein Wert, der sich nicht geändert hat, nicht gesendet wird. Evtl. nimmst Du das mal raus, damit jeder Wert gesendet wird, sonst wird es unübersichtlich beim testen.
in der Mitte wird es interessant:
ceil() dient zum runden von Fliesskommazahlen: es ermittelt von der Fliesskommazahl x die kleinste Ganzzahl (Integer) die größer als x ist. Also 1.1 wird 2.
Davor steht noch mal int(), was eigenlich eine beliebigen Datentyp zu int konvertiert.
Da die Variable aber ein unsigned int ist, also eine Ganzzahl zwischen 0 und 65xxx, macht weder int() noch ceil() einen Sinn, im Gegenteil, man kann vermutlich nicht sagen, was dabei herauskommt. Dieses wird aber an fhem übermittelt und Du wunderst Dich, dass die Werte nicht übereinstimmen.
also einfach
gw.send(msg.set(valMQ));und gut ist.
Probier das mal, und dann wäre noch die Frage offen, ob denn in fhem jetzt was ankommt.
Viel Erfolg!
sany
Die Lösung mit der statischen IP funktioniert doch nicht.
Wenn man nicht bis ganz zu Ende testet...
Neben meinem 1. Gateway (DHCP, ESP8266-12e) habe ich parallel ein weiteres zusammengebaut (ein ESP8266-12, jetzt mit statischer IP). Nachdem sich das 2. Gateway mit der gewünschten IP mit dem Router verbunden hat, dachte ich: Ziel erreicht.
Da ich jetzt den ESP8266-12e für etwas anderes verwenden möchte, habe ich in FHEM das andere Gateway genommen und es auf seine statische IP eingerichtet. Aber: in FHEM beim Gateway steht immer nur ,,disconnected". Ein set gateway connect hilft nicht. (ich habe nie beide Gateways parallel eingerichtet sondern nur die Definition des bereits eingerichteten Gateways angepasst).
Ich habe nicht nur die Definition auf die neue IP geändert, ich habe auch das Device komplett gelöscht (ging nicht über die Oberfläche, musste hart in der fhem.cfg editieren) und neu eingerichtet.
Hat alles nichts genützt. Erst als ich wieder auf DHCP umgestellt habe, habe ich sofort den Status ,,opened" bekommen.
Es ist vollkommen egal, ob ich den ESP-12 oder den 12e nehme – immer das gleiche Verhalten.
Versuche mal mit PuTTY drauf (IP:PORT) zu konnekten, klappt das und was sieht man dann?
Das Gateway mit der statischen IP ist im Netzwerk. Ich sehe es sowohl im Router (angemeldet) als auch in der ARP-Tabelle.
Wenn ich mit Putty draufgehe, kommt nach einer Weile: Connection timed out. Also nichts zu sehen.
Beim Gateway (über DHCP verbunden) kommt mit Putty:
0;0;3;0;14;Gateway startup complete.
100;0;1;0;1;52.0
Da stimmt alles.
Im Netz sind Hinweise zu finden über die Reihenfolge von wifi.config und wifi.begin. Habe beide Varianten probiert - kein Unterschied bei mir.
Zitat von: Sany am 21 November 2015, 16:38:41
Hallo neonet
verwendest Du den Sketch aus Post #564?
Ich habe mir den mal angeschaut und würde dort ein paar Änderungen vornehmen:
so steht er auf Github:
void loop()
{
uint16_t valMQ = MQGetGasPercentage(MQRead(MQ_SENSOR_ANALOG_PIN)/Ro,GAS_CO);
//Start Test
uint16_t valMQ2 = MQGetGasPercentage(MQRead(MQ_SENSOR_ANALOG_PIN)/Ro,GAS_LPG);
uint16_t valMQ3 = MQGetGasPercentage(MQRead(MQ_SENSOR_ANALOG_PIN)/Ro,GAS_SMOKE);
//Ende Test
Serial.println(val);
Serial.print("LPG:");
Serial.print(MQGetGasPercentage(MQRead(MQ_SENSOR_ANALOG_PIN)/Ro,GAS_LPG) );
Serial.print( "ppm" );
Serial.print(" ");
Serial.print("CO:");
Serial.print(MQGetGasPercentage(MQRead(MQ_SENSOR_ANALOG_PIN)/Ro,GAS_CO) );
Serial.print( "ppm" );
Serial.print(" ");
Serial.print("SMOKE:");
Serial.print(MQGetGasPercentage(MQRead(MQ_SENSOR_ANALOG_PIN)/Ro,GAS_SMOKE) );
Serial.print( "ppm" );
Serial.print("\n");
//Start Test
if (valMQ != lastMQ) {
gw.send(msg.set((int)ceil(valMQ)));
lastMQ = ceil(valMQ);
}
if (valMQ2 != lastMQ2) {
gw.send(msgLPG.set((int)ceil(valMQ2)));
lastMQ2 = ceil(valMQ2);
}
if (valMQ3 != lastMQ3) {
gw.send(msgSMOKE.set((int)ceil(valMQ3)));
lastMQ3 = ceil(valMQ3);
}
//Ende Test
gw.sleep(SLEEP_TIME); //sleep for: sleepTime
}
Am Anfang der Loop wird der Sensor ausgelesen und die ermittelten Werte in variablen geschrieben. Diese sind als unsigned int deklariert, also nur positive Ganzzahlen.
Gleich danach werden sie auf der Konsole ausgegeben, aber hier werden die Sensoren nochmals gelesen. Das macht keinen Sinn, denn 2 mal Sensor auslesen bringt ziemlich sicher 2 verschiedene Werte. Also besser:
Serial.print("LPG:");
Serial.print(GAS_LPG);
Serial.print( "ppm" );
das druckt die den Inhalt der Variablen, die Du ja gerade mit dem Sensorwert gefüttert hast. Die anderen 2 Zeilen bitte entsprechend anpassen.
dann kommt der Sendeteil:
if (valMQ != lastMQ) {
gw.send(msg.set((int)ceil(valMQ)));
lastMQ = ceil(valMQ);
}
erste und letzte Zeile sorgen ja nur dafür, dass ein Wert, der sich nicht geändert hat, nicht gesendet wird. Evtl. nimmst Du das mal raus, damit jeder Wert gesendet wird, sonst wird es unübersichtlich beim testen.
in der Mitte wird es interessant:
ceil() dient zum runden von Fliesskommazahlen: es ermittelt von der Fliesskommazahl x die kleinste Ganzzahl (Integer) die größer als x ist. Also 1.1 wird 2.
Davor steht noch mal int(), was eigenlich eine beliebigen Datentyp zu int konvertiert.
Da die Variable aber ein unsigned int ist, also eine Ganzzahl zwischen 0 und 65xxx, macht weder int() noch ceil() einen Sinn, im Gegenteil, man kann vermutlich nicht sagen, was dabei herauskommt. Dieses wird aber an fhem übermittelt und Du wunderst Dich, dass die Werte nicht übereinstimmen.
also einfach
gw.send(msg.set(valMQ));
und gut ist.
Probier das mal, und dann wäre noch die Frage offen, ob denn in fhem jetzt was ankommt.
Viel Erfolg!
sany
Hallo sany, ich schaue mir morgen deinen Vorschlag mal genauer an und korrigierte meine Version. Gruß
Zitat von: Omega am 22 November 2015, 16:54:12
Das Gateway mit der statischen IP ist im Netzwerk. Ich sehe es sowohl im Router (angemeldet) als auch in der ARP-Tabelle.
Wenn ich mit Putty draufgehe, kommt nach einer Weile: Connection timed out. Also nichts zu sehen.
Beim Gateway (über DHCP verbunden) kommt mit Putty:
0;0;3;0;14;Gateway startup complete.
100;0;1;0;1;52.0
Da stimmt alles.
Im Netz sind Hinweise zu finden über die Reihenfolge von wifi.config und wifi.begin. Habe beide Varianten probiert - kein Unterschied bei mir.
Sehr seltsam, stimmen die Werte für Subnet und Gateway und dns? Vor allem Subnet wäre wichtig. Ich muss bei mal mit meiner Hardware ausprobieren. Habe nur zeittechnisch etwas eng...
Zitat von: Hauswart am 22 November 2015, 18:29:25
Hallo sany, ich schaue mir morgen deinen Vorschlag mal genauer an und korrigierte meine Version. Gruß
Hallo neonet,
bitte mal diese Version testen: https://raw.githubusercontent.com/Kolbi/Arduino/master/libraries/MySensors/examples/AirQualitySensor/AirQualitySensor.ino 8)
Hallo zusammen,
eine Frage zum Wifi GW und der festen IP. Klappt das bei jemandem mitlerweile gut oder ist der Punkt noch offen...danke
Zitat von: Peter_64 am 17 Dezember 2015, 13:58:08
Hallo zusammen,
eine Frage zum Wifi GW und der festen IP. Klappt das bei jemandem mitlerweile gut oder ist der Punkt noch offen...danke
Ich weiß jetzt nicht ob bei dir "feste IP" ein Kriterium ist, aber das WLAN-Gateway läuft schon bei mir im "Produktivbetrieb" seit Mitte Oktober 2015. Keine Störungen.
https://blog.moneybag.de/fhem-wlan-gateway-mit-mysensors-ohne-zu-loeten/
LG
/robin
Hallo Robin,
das auf Deinem Block hatte ich gelesen und hat mir sehr geholfen um das GW zum laufen zu bringen. Meinte mit der Frage ob man im GW eine feste IP speichern kann die sich dann im Netz einloggt. Oder ist es so das die IP die beim ersten Start des GW festgelegt wird im GW fest gespeichert ist.
Hallo in die Runde,
da ich bisher nichts passendes gefunden habe, hat bereits jemand ein funktionierendes Code Beispiel, mit dem man eine Nachricht an das Gateway wiederholen kann insofern, dieses das angeforderte Ack nicht an den Sensor zurückliefert?
Ich habe mit meinen Luftfeuchte & Bewegungsmelder Kombisensoren ab und zu das Problem, dass der gemeldete Zustand (Bewegung/keine Bewegung) nicht immer über das Serial Gateway, mit NRF24L01+PA+LNA Funkmodul, in Fhem, ankommt.
Daher würde ich die Meldung gerne erneut senden lassen.
Greetz
Eldrik
Hallo zusammen
ich habe einen esp8266-Gateway (NodeMCU) an meinem FHEM angehängt und empfange von 2 Sensoren Daten. Der eine Sensor ist ein Temp/Hum-Sensor mit einem DHT22. Das klappt soweit ganz gut. Die Daten kommen an, die Hum-Daten zuverlässiger als die Temp-Daten.
Als zweiten Sensor habe ich einen Lux-Meter mit einem Arduino und einem BH1750 angehängt. Auch da kommen die Daten im FHEM an. D.h. wenn ich den Sensor neu starte, zeigt mir das FHEM auch den korrekten Lux-Wert an:
Restart:
send: 100-100-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,st=ok:1.5.1
send: 100-100-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=ok:0
sensor started, id=100, parent=0, distance=1
send: 100-100-0-0 s=255,c=3,t=11,pt=0,l=16,sg=0,st=ok:Light Lux Sensor
send: 100-100-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=ok:1.0
send: 100-100-0-0 s=0,c=0,t=16,pt=0,l=0,sg=0,st=ok:
114
send: 100-100-0-0 s=0,c=1,t=23,pt=3,l=2,sg=0,st=ok:114
Event-Log:
s016-01-05 09:10:01 MYSENSORS_DEVICE MYSENSOR_100 parentId: 0
2016-01-05 09:10:03 MYSENSORS_DEVICE MYSENSOR_100 SKETCH_NAME: Light Lux Sensor
2016-01-05 09:10:03 MYSENSORS_DEVICE MYSENSOR_100 SKETCH_VERSION: 1.0
2016-01-05 09:10:03 MYSENSORS_DEVICE MYSENSOR_100 brightness: 114
Reading:
Readings:
2016-01-05 09:10:03 SKETCH_NAME Light Lux Sensor
2016-01-05 09:10:03 SKETCH_VERSION 1.0
2016-01-05 09:10:03 brightness 114
2016-01-05 09:10:01 parentId 0
Jedoch nach ein paar Messwerten bekommt das FHEM irgendwie das mit den Messwerten nicht mehr hin:
Serial-Monitor Sensor:
112
send: 100-100-0-0 s=0,c=1,t=23,pt=3,l=2,sg=0,st=ok:112
113
send: 100-100-0-0 s=0,c=1,t=23,pt=3,l=2,sg=0,st=ok:113
113
114
send: 100-100-0-0 s=0,c=1,t=23,pt=3,l=2,sg=0,st=ok:114
Eventlog:
2016-01-05 09:10:36 MYSENSORS_DEVICE MYSENSOR_100 brightness: 112
2016-01-05 09:11:09 MYSENSORS_DEVICE MYSENSOR_100 brightness: 113
2016-01-05 09:12:04 MYSENSORS_DEVICE MYSENSOR_1 humidity: 39.4
2016-01-05 09:12:16 MYSENSORS_DEVICE MYSENSOR_100 brightness: 1107296370
2016-01-05 09:12:49 MYSENSORS_DEVICE MYSENSOR_100 brightness: 1107296369
Readings:
Readings:
2016-01-05 09:10:03 SKETCH_NAME Light Lux Sensor
2016-01-05 09:10:03 SKETCH_VERSION 1.0
2016-01-05 09:12:49 brightness 1107296369
2016-01-05 09:10:01 parentId 0
Erst durch ein Restart des Sensors bekommt das FHEM wieder entsprechende Daten. Aber auch nur 2-3 Messwerte. Es sieht aber so aus, als sende der Sensor korrekte Messwerte.
Meine Device-Config:
Internals:
CFGFN /opt/fhem/mycfg/62_sensors.cfg
DEF 100
IODev XX_mysensors_wlan
I_SKETCH_NAME Light Lux Sensor
I_SKETCH_VERSION 1.0
NAME MYSENSOR_100
NR 933
STATE ???
TYPE MYSENSORS_DEVICE
ack 0
protocol 1.5.1
radioId 100
repeater 0
Readings:
2016-01-05 09:00:29 SKETCH_NAME Light Lux Sensor
2016-01-05 09:00:29 SKETCH_VERSION 1.0
2016-01-05 09:02:42 brightness 1107296367
2016-01-05 09:00:27 parentId 0
Attributes:
IODev XX_mysensors_wlan
group mySensors
mapReading_brightness 0 brightness
mapReading_level 0 level
mode node
room MySensors
verbose 5
version 1.5.1
Hat jemand einen Rat?
Greets
Tom
Anm: habe noch heute noch einen Distanzmesser hinzugefügt. Auch dort das Phänomen:
Sensordaten:
sensor started, id=101, parent=0, distance=1
send: 101-101-0-0 s=255,c=3,t=11,pt=0,l=15,sg=0,st=ok:Distance Sensor
send: 101-101-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=ok:1.0
send: 101-101-0-0 s=1,c=0,t=15,pt=0,l=0,sg=0,st=ok:
Ping: 6 cm
send: 101-101-0-0 s=1,c=1,t=13,pt=2,l=2,sg=0,st=ok:6
Ping: 25 cm
send: 101-101-0-0 s=1,c=1,t=13,pt=2,l=2,sg=0,st=ok:25
Ping: 66 cm
send: 101-101-0-0 s=1,c=1,t=13,pt=2,l=2,sg=0,st=ok:66
Ping: 15 cm
send: 101-101-0-0 s=1,c=1,t=13,pt=2,l=2,sg=0,st=ok:15
Ping: 10 cm
send: 101-101-0-0 s=1,c=1,t=13,pt=2,l=2,sg=0,st=ok:10
Ping: 0 cm
send: 101-101-0-0 s=1,c=1,t=13,pt=2,l=2,sg=0,st=ok:0
Ping: 69 cm
send: 101-101-0-0 s=1,c=1,t=13,pt=2,l=2,sg=0,st=ok:69
Ping: 121 cm
send: 101-101-0-0 s=1,c=1,t=13,pt=2,l=2,sg=0,st=ok:121
Ping: 208 cm
send: 101-101-0-0 s=1,c=1,t=13,pt=2,l=2,sg=0,st=ok:208
Ping: 219 cm
send: 101-101-0-0 s=1,c=1,t=13,pt=2,l=2,sg=0,st=ok:219
Ping: 63 cm
send: 101-101-0-0 s=1,c=1,t=13,pt=2,l=2,sg=0,st=ok:63
Ping: 140 cm
send: 101-101-0-0 s=1,c=1,t=13,pt=2,l=2,sg=0,st=ok:140
Ping: 0 cm
send: 101-101-0-0 s=1,c=1,t=13,pt=2,l=2,sg=0,st=ok:0
Ping: 141 cm
send: 101-101-0-0 s=1,c=1,t=13,pt=2,l=2,sg=0,st=ok:141
Ping: 107 cm
send: 101-101-0-0 s=1,c=1,t=13,pt=2,l=2,sg=0,st=ok:107
Ping: 106 cm
send: 101-101-0-0 s=1,c=1,t=13,pt=2,l=2,sg=0,st=ok:106
Ping: 56 cm
send: 101-101-0-0 s=1,c=1,t=13,pt=2,l=2,sg=0,st=ok:56
Ping: 41 cm
send: 101-101-0-0 s=1,c=1,t=13,pt=2,l=2,sg=0,st=ok:41
Ping: 47 cm
send: 101-101-0-0 s=1,c=1,t=13,pt=2,l=2,sg=0,st=ok:47
Ping: 39 cm
send: 101-101-0-0 s=1,c=1,t=13,pt=2,l=2,sg=0,st=ok:39
Ping: 6 cm
send: 101-101-0-0 s=1,c=1,t=13,pt=2,l=2,sg=0,st=ok:6
Ping: 6 cm
Ping: 6 cm
Ping: 6 cm
Im Enventlog:
2016-01-06 20:08:11 Global global ATTR MYSENSOR_101 mode node
2016-01-06 20:08:11 Global global ATTR MYSENSOR_101 version 1.5.1
2016-01-06 20:08:11 MYSENSORS_DEVICE MYSENSOR_101 parentId: 0
2016-01-06 20:08:13 MYSENSORS_DEVICE MYSENSOR_101 SKETCH_NAME: Distance Sensor
2016-01-06 20:08:13 MYSENSORS_DEVICE MYSENSOR_101 SKETCH_VERSION: 1.0
2016-01-06 20:08:13 MYSENSORS_DEVICE MYSENSOR_101 distance1: 6
2016-01-06 20:08:19 MYSENSORS_DEVICE MYSENSOR_101 distance1: 25
2016-01-06 20:08:24 MYSENSORS_DEVICE MYSENSOR_101 distance1: 66
2016-01-06 20:08:30 MYSENSORS_DEVICE MYSENSOR_101 distance1: 15
2016-01-06 20:08:35 MYSENSORS_DEVICE MYSENSOR_101 distance1: 10
2016-01-06 20:08:41 MYSENSORS_DEVICE MYSENSOR_101 distance1: 0
2016-01-06 20:08:47 MYSENSORS_DEVICE MYSENSOR_101 distance1: 69
2016-01-06 20:08:52 MYSENSORS_DEVICE MYSENSOR_101 distance1: 121
2016-01-06 20:08:58 MYSENSORS_DEVICE MYSENSOR_101 distance1: 208
2016-01-06 20:09:03 MYSENSORS_DEVICE MYSENSOR_101 distance1: 219
2016-01-06 20:09:09 MYSENSORS_DEVICE MYSENSOR_101 distance1: 63
2016-01-06 20:09:14 MYSENSORS_DEVICE MYSENSOR_101 distance1: 140
2016-01-06 20:09:20 MYSENSORS_DEVICE MYSENSOR_101 distance1: 0
2016-01-06 20:09:26 MYSENSORS_DEVICE MYSENSOR_101 distance1: 141
2016-01-06 20:09:31 MYSENSORS_DEVICE MYSENSOR_101 distance1: 107
2016-01-06 20:09:37 MYSENSORS_DEVICE MYSENSOR_101 distance1: 106
2016-01-06 20:09:42 MYSENSORS_DEVICE MYSENSOR_101 distance1: 56
2016-01-06 20:09:48 MYSENSORS_DEVICE MYSENSOR_101 distance1: 41
2016-01-06 20:09:53 MYSENSORS_DEVICE MYSENSOR_101 distance1: 47
2016-01-06 20:09:59 MYSENSORS_DEVICE MYSENSOR_101 distance1: 39
2016-01-06 20:10:04 MYSENSORS_DEVICE MYSENSOR_101 distance1: 1107296262
Was mir noch auffällt sind die "fast" gleichen Fehlwerte.
Hallo, hier das gleiche mit einem DHT22-Sensor.
Es wird bei neustart des Sensors einmalig die Temperatur übernommen und anschließend wird zwar das Senden des Sensors erkannt, allerdings wieder mit dem gleichen Wert wie davor. Hab den dann anschließend rausgetragen und glab nicht, dass es draußen grade 20° hat :D
Zitat von: Kuzl am 08 Januar 2016, 10:53:58
Hallo, hier das gleiche mit einem DHT22-Sensor.
Es wird bei neustart des Sensors einmalig die Temperatur übernommen und anschließend wird zwar das Senden des Sensors erkannt, allerdings wieder mit dem gleichen Wert wie davor. Hab den dann anschließend rausgetragen und glab nicht, dass es draußen grade 20° hat :D
Hallo,
habe auch das Problem, beim auswerten eines Analog Ports. Denke aber es liegt am Sketch muss noch probieren. Da ich einige Multisensoren mit Sketch von Alex am laufen habe, bei denen gibt es keine Probleme.
Ich habe dieses Problem auch mit einem Sensebender board, Temperatur und battery wird richtig dargestellt, Humidity habe ich immer solche unwahrscheinlichen Werte wie z.b. 1090519074.
Den Sensor habe ich über die serielle ausgelesen, dieser sendet die richtigen Werte.
Das mit dem resetten des gateways bringt auch nichts mehr, hatte es aber ganz zu Beginn. Leider streikt mein serielles USB Gateway auch, deswegen konnte ich noch nicht überprüfen was wirklich gefunkt wird, aber ich habe stark das gateway in Verdacht.
Sent from my iPad using Tapatalk
Ich nutze auch die Sensebender.
Ich habe einen Sensebender am Raspberry Pi als Gateway in Betrieb und mit dem aktuellen MySensors Stand in FHEM funktioniert alles ohne Probleme. Humidity, Temperatur und Batterielevel werden korrekt gesendet, empfangen und dargestellt.
Welche Version verwendet ihr? 1.5 oder Development?
Ich hatte gestern auch komische Temperatur Werte (Gateway 1.5), nachdem ich einen zweiten Seriellen Gateway in Betrieb hatte (Development), dass komische war, dass die Sensoren weiterhin mit dem 1.5 gekoppelt waren und das neue Gateway wirklich nur im Seriellen Modus lief also quasi den Funkverkehr mit geschnitten hatte.
Ich verwende durchweg für Gateway und Sensoren die V1.5
Hallo,
ist es möglich, dass ich mein Gateway auch als Sensor benutzen kann und er sich fhem wie ein normales MySensors Device präsentiert?
Ich möchte mein Gateway noch weitere Aufgaben übernehmen lassen, brauche aber eine Kommunikation zwischen fhem auf meinem Raspberry Pi und dem Gateway Arduino, das über USB angeschlossen ist.
Daher dachte ich mir, dass das Gateway fhem einfach vorgaukelt, ein MySensors device mit x-beliebiger ID zu sein und ich dann werte zwischen beiden Systemen austauschen kann.
Vielen Dank im Voraus!
Gruß,
Mathea
Zitat von: Mathea am 08 Januar 2016, 15:04:36
Daher dachte ich mir, dass das Gateway fhem einfach vorgaukelt, ein MySensors device mit x-beliebiger ID zu sein und ich dann werte zwischen beiden Systemen austauschen kann.
Technich spricht nichts dagegen. Alledings wird out-of-the-box nichts. Das Zeug zum Abfragen der Sensoren und Schreiben der entprechenden Messages über die serielle Schnittstelle musst Du reinprogrammieren.
Sensoren und Gateway alles 1.5
Auch bei mir sind sowohl die Sensoren wie auch der Gateway von der Version 1.5. Interessant ist, das auch schka17 auch komische Werte erhält. Und dies mit einem seriellen Gateway. Ich verwende ein Wifi-Gateway.
Lässt sich das Modul MYSENSORS_DEVICE noch genauer debuggen? Verbose 5 bringt keine weiteren Ausgaben.
Gesendet von iPhone mit Tapatalk
Auch bei mir sind sowohl die Sensoren wie auch der Gateway von der Version 1.5. Interessant ist, das auch schka17 auch komische Werte erhält. Und dies mit einem seriellen Gateway. Ich verwende ein Wifi-Gateway.
Lässt sich das Modul MYSENSORS_DEVICE noch genauer debuggen? Verbose 5 bringt keine weiteren Ausgaben.
Gesendet von iPhone mit Tapatalk
Zitat von: MrTom am 08 Januar 2016, 17:10:12
Auch bei mir sind sowohl die Sensoren wie auch der Gateway von der Version 1.5. Interessant ist, das auch schka17 auch komische Werte erhält. Und dies mit einem seriellen Gateway. Ich verwende ein Wifi-Gateway.
Lässt sich das Modul MYSENSORS_DEVICE noch genauer debuggen? Verbose 5 bringt keine weiteren Ausgaben.
Gesendet von iPhone mit Tapatalk
das Problem habe ich auch mit dem Wifi Gateway, das serielle ist mir, warum auch immer, abgeraucht (FTDI CHip), und der neue Nano weigert sich noch mit dem NRF zu sprechen....
Leider kann ich beim produktiven Wifi Gateway im moment nichts herumbasteln da eben das serielle im Moment auch nicht funktioniert.
Ich hatte zuerst ein serielles Gateway am RPi. Da hatte ich aber Stabilitätsprobleme, d.h. fhem hat nach ein paar Stunden über die Schnittstelle nur noch Sonderzeichen angezeigt. Ich ging davon aus, dass das mit den beiden anderen Funkgateways (jeelink und ali-rf) zu tun haben könnte. Ein Aus-/Einstecken hat dann jeweils geholfen.
Seit Inbetriebnahme des Wifi-Gateways hatte ich keine Probleme mit dem Empfang. Jedoch mit den Werten. :(
Gesendet von iPhone mit Tapatalk
Es scheint also irgendwie am Wifi Gateway zu liegen.
Das serielle hat die Probleme ja nicht.
Ich hatte zuerst ein serielles Gateway am RPi. Da hatte ich aber Stabilitätsprobleme, d.h. fhem hat nach ein paar Stunden über die Schnittstelle nur noch Sonderzeichen angezeigt. Ich ging davon aus, dass das mit den beiden anderen Funkgateways (jeelink und ali-rf) zu tun haben könnte. Ein Aus-/Einstecken hat dann jeweils geholfen.
Seit Inbetriebnahme des Wifi-Gateways hatte ich keine Probleme mit dem Empfang. Jedoch mit den Werten. :(
Gesendet von iPhone mit Tapatalk
Zitat von: MrTom am 08 Januar 2016, 17:09:55
Auch bei mir sind sowohl die Sensoren wie auch der Gateway von der Version 1.5. Interessant ist, das auch schka17 auch komische Werte erhält. Und dies mit einem seriellen Gateway. Ich verwende ein Wifi-Gateway.
Lässt sich das Modul MYSENSORS_DEVICE noch genauer debuggen? Verbose 5 bringt keine weiteren Ausgaben.
Ich bin mal direkt mit Telnet auf das Gateway gegangen:
5;255;0;0;17;1.5
5;255;3;0;6;102
5;255;3;0;11;Sensebender Micro
5;255;3;0;12;1.3v2
5;1;0;0;6;
5;2;0;0;7;
5;199;0;0;13;
5;1;1;0;0;24.4
[b]5;2;1;0;1;1090519073[/b]
5;199;1;0;38;2992
5;255;3;0;0;78
Über das serielle Gateway kommen die humidity richtig rein.
0;0;3;0;9;gateway started, id=0, parent=0, distance=0<\n>0;0;3;0;14;Gateway startup complete.<\n>0;0;3;0;9;read: 5-102-0 s=255,c=0,t=17,pt=0,l=10,sg=0:1.5<\n>5;255;0;0;17;1.5<\n>0;0;3;0;9;read: 5-70-0 s=1,c=1,t=0,pt=7,l=5,sg=0:24.9<\n>5;1;1;0;0;24.9<\n>
Also liegts wahrscheinlich irgendwo am Wifi Gateway zwischen esp und nrf.
Das Problem dürfte effektiv am Wifi-Gateway liegen. Das Problem wird hier beschrieben: http://forum.mysensors.org/topic/2118/esp8266-wifi-gateway-issue/7
@Yveaux said:
Possibly a variable somewhere that has a different size on ESP
Pretty sure I found the cause: the messages exchanged between sensor and gateway contain int types.
These have a size of 2 bytes on Arduino and 4 bytes on ESP.
An int sent from the Arduino is sent as 2 bytes, but the ESP expects 4. The upper 2 will be filled with garbage.
Still a hypothesis which has to be verified & fixed.
To be continued!
Als Lösung wird die Verwendung der development-Version beschrieben. Diese krieg ich aber noch nicht zum Laufen. Viele compilation-Fehler.
Ich versuchs weiter....
Hallo MrTom,
Das compilieren und flashen 0;255;3;0;2;1.6.0-betaauf eine NodeMCU 0.9 ist bei mir ohne Probleme gelaufen. Schaut auch soweit mal besser aus (1h bis jetzt). allerdings habe ich auf dem seriellen Gateway ein paar falsche Werte, vor allem ab und zu minus Werte, etwa 3-4 mal pro Tag, und das gemischt bei meinen beiden Sensoren, also Sensebender micro und Nano mit DHT22. Lasse jetzt mal das WIFI Gateway laufen und beobachte das mal.
Sent from my iPad using Tapatalk
Schade eigentlich, die vielen Probleme mit MySensors, ESP-Gateway usw.
Wenn ein Neuling die mysensors-Seite anschaut, denkt er, wow , alles ganz einfach, viele Bilder, mal kurz nachbauen.
Doch dann beginnen die Probleme, oft funktioniert es nicht, verschiedene Arduino-IDEs , für den ESP sind spezielle Core-Versionen notwendig, vernünftige Erklärungen gibt es wenige, meist wird zur Developer-Version geraten, die aber natürlich genau in dem Moment, wie der Name sagt, eine Developer-Version ist, und es deshalb normal ist das sie nicht funktioniert.
Verschiedene Sensoren zusammen fassen, evtl. auch noch Batterieüberwachung und paar Kleinigkeiten, immer scheitert es an irgend was.
Wie sind denn Eure Erfahrungen ? Ich hatte eigentlich gehofft, es ist ein System wie z.B. Homematic, nur halt Selbstbau, und es läuft einfach, aber in Meinen Augen rennen die Jungs dort nach vorne mit neuen Themen wie Signierung, OTA-Flash usw., ein Neueinsteiger hat Probleme zu folgen
Ich würde mich freuen, wenn wir hier einen Parallelthread aufmachen könnten, das Ganze angepasst an FHEM, vielleicht eine neue Gruppe MySensors/ESPEasy ?
Nun ja...
Das ist eben der Unterschied zwischen einem kommerziellen und einem Bastler-System. HomeMatic wäre übrigens noch schwieriger selbst aufzubauen. Aber auch hier muss man sich etwas Ahnung von Materie aneignen. Die Flexibilität bedeutet immer eine gewisse Komplexität. Einfacher könnte man das vermutlich nur durch eine Beschränkung auf wenige feste Kombinationen machen. Aber eben das würde das System unattraktiv machen.
Zu einer Developer-Versionwürde ich nur jemandem anraten, der weiß, was er tut, sonst ist der Frust unvermeidlich. Eigentlich für einen Produktiv-Betrieb ungeeignet.
Meine Erfahrung mit dem System ist weitgehend positiv. Eigentlich funktioniert letztendlich doch alles. Auch wenn man nicht immer gleich und auf einer geraden Strecke zum Ziel kommt ;D Und ich hoffe doch, dass "die Jungs" so "weiter rennen", davon lebt ja das Ganze.
Wo "hängst" Du denn grade? Was funktioniert nicht?
Eigentlich funktioniert es bei mir schon, habe einige Sensoren damit gebastelt, laufen auch rel. zuverlässig.
Was nicht so recht laufen will, ist der ESP-Gateway, immer wieder Reboot beim anlernen, hatte hier auch schon einige andee Threads dazu
Aber was mich zugegeben stört, ist das ich z.B. mal vor einem Jahr einen Sensor gebaut habe, jetzt brauche ich genau so einen noch mal, dann ist plötzlich die IDE nicht mehr kompatibel.
Auch ist die Reichweite sehr gering, hierzu gibts dort im Forum verschiedene Ansätze, aber nichts konkretes, viele Vermutungen über gefälschte Chips...
Das Thema Quittierung von gesendeten Befehlen / erneut senden ist auch nicht wirklich beantwortet, ist wohl letztendlich eine Sache des Controllers, in diesem Fall FHEM ?
Ich finde das System grundsätzlich genial, aber für mich wirkt es leider momentan so, das viele Dinge aus der Anfangszeit gar nicht mehr funktionieren, es für einen Anfänger kaum möglich ist, das zum laufen zu bekommen ?
Ich würde jetzt mal behaupten, ich kenne mich schon rel. gut mit so was aus, aber "mal eben kurz was fertig machen" ist leider nicht
Zum Anlernen kann ich nichts sagen, habe noch nie bei meinem ESP-Gateway Inclusion gesetzt. Muss ich mal probieren.
Was war eigentlich in IDE nicht mehr kompatibel? Meinst Du den Übergang von Version 1.4 auf 1.5 bei eigenen Sketches?
Für die Reichweite kann MySensors nichts. Das hat etwas mit den fverwendeten Transceiver zu tun. 2,4GHz wird nun mal stärker gedämpft als 868. Es gibt aber neuerdings die Möglichkeit, einen RFM69 anstatt nRF24L01+ zu verwenden. Außerdem bint es Repeater und ggf. kann man mehere Gateways installieren. An gefälschte nRF-Chips glaube ich nicht. Die sind schon so billig (z.B. im Vergleich mit CC1101), dass es sich nicht lohnen dürfte.
Die Quittierung von gesendeten Befehlen muss von dem Controller angefordert werden. Das kann man mit FHEM machen, aber ob auch Resent implementiert ist, das weiß ich jetzt nicht. Habe keine Erfahrung damit, da ich MySensors rein als Sensor-Netzwerk verwende. Alle Aktoren sind dagegen HomeMatic.
"Mal eben kurz fertig machen" funktioniert ja bei MySensors sogar, wenn man nichts ändert und genau die Beispiele nachmacht. Das dürfte für einen Anfänger zwar reichen, man wird aber bald mehr wollen. Die Anforderungen und Wünsche werden dabei sehr individuell. Das kann man mit der Einfachheit nicht mehr gut vereinbaren.
Zitat von: Klaus0815 am 11 Januar 2016, 01:34:27
Das Thema Quittierung von gesendeten Befehlen / erneut senden ist auch nicht wirklich beantwortet, ist wohl letztendlich eine Sache des Controllers, in diesem Fall FHEM ?
Die Quittierung macht der Controller (also FHEM). Kann man entweder global am MYSENSORS-gateway device oder auch per MYSENSORS_DEVICE client-device per 'Attr <MYSENSORS-device> requestAck 1' aktivieren. Wenn die Message vom Sensor/Aktor nicht quittiert wird, wird sie (in größer werdenden Abständen) immer wieder geschickt. Dafür scheduled das MYSENSORS modul immer einen Timer (https://github.com/ntruchsess/fhem-mirror/blob/dev/fhem/FHEM/00_MYSENSORS.pm#L221), der die jeweils nächsten noch nicht quittierten Messages wiederholt.
Das Gateway ist diesbezüglich 'dumm'. Muss natürlich in den jeweiligen Sensoren/Aktoren auch funktionieren, sonst werden die Messages endlos wiederholt.
Wie lernst Du denn die Sensoren an, wenn Du den Inclusion-Mode nicht nutzt ? Gibst Du allen eine feste ID ?
Die Kompatibilitätsprobleme kommen durch den Umstieg von 1.4 auf 1.5
Soweit ich weiß hat Hexenmeister auch ein Serial Gateway.
Zitat
Wenn die Message vom Sensor/Aktor nicht quittiert wird, wird sie (in größer werdenden Abständen) immer wieder geschickt.
Taucht diese Information irgend wo in einem Log auf? Bei Homematic gibt es Konstellationen, wo dieser Sachverhalt nicht weitergeben wird. Dann hat man auch keine Chance auf eine rechtzeitige Reaktion.
Zitat von: Klaus0815 am 11 Januar 2016, 14:41:57
Wie lernst Du denn die Sensoren an, wenn Du den Inclusion-Mode nicht nutzt ? Gibst Du allen eine feste ID ?
Die Kompatibilitätsprobleme kommen durch den Umstieg von 1.4 auf 1.5
Wenn einen neuen Server 'bespiele', vergebe ich die ID tatsächlich erstmalig durch mein Serial-Gateway. Wenn ich eine ganz bestimmte ID schon haben will, dann stele ich sie einmalig als zweiter Parameter der MySensor-Begin-Aufruf im Sketch ein. Dabei wird die ID in EEPROM geschrieben, danach kann man im Sketch wieder auf AUTO setzen.
Bei Versonssprüngen sid die Inkompatibilitäten leider oft unvermeidlich. Aber eben ein Anfänger, der Sketches von MySensors.org nimmt, wird dieses Problem gar nicht erst haben.
Zitat von: Omega am 11 Januar 2016, 16:13:39Taucht diese Information irgend wo in einem Log auf?
Sieht man wenn man den loglevel >= 5 stellt.
Zitat
Wenn einen neuen Server 'bespiele', vergebe ich die ID tatsächlich erstmalig durch mein Serial-Gateway. Wenn ich eine ganz bestimmte ID schon haben will, dann stele ich sie einmalig als zweiter Parameter der MySensor-Begin-Aufruf im Sketch ein. Dabei wird die ID in EEPROM geschrieben, danach kann man im Sketch wieder auf AUTO setzen
Du weisst danach dann einfach in FHEM dem Sensor den anderen Gateway zu?
Was ist die Parent-ID im Sensor ?
Könnte mal jemand versuchen, ob der Inclusion-Mode am ESP-Gateway funktioniert ?
Ich will / muss bei mir mehrere Gateways parallel einsetzten, und man soll ja dann unbedingt die Frequenz von Gateway/sensor unterschiedlich halten, deshalb kann ich es nicht am anderen Gateway anlernen
(Notfalls baue ich mir sonst noch mal einen zus. "anlern-Gateway"
Inclusion mode beim ESP Gateway funktioniert im fhemweb, ich habe keinen Taster am Gateway
Sent from my iPad using Tapatalk
Zitat von: Klaus0815 am 11 Januar 2016, 23:36:01
Du weisst danach dann einfach in FHEM dem Sensor den anderen Gateway zu?
Was ist die Parent-ID im Sensor ?
Jep. Ich meine alle Gateways habe die gleiche ID.
Zitat von: Klaus0815 am 11 Januar 2016, 23:36:01
Ich will / muss bei mir mehrere Gateways parallel einsetzten, und man soll ja dann unbedingt die Frequenz von Gateway/sensor unterschiedlich halten, deshalb kann ich es nicht am anderen Gateway anlernen
Warum? Ich hab drei Gateways und alle Sensoren benutzen gleichen Kanäle. Zum Teil 'sehen' sie sich auch gegenseitig. Das einzige 'Nebenwirkung' sind Einträge im Log wenn ein Gateway einen ihm unbekannten Sensor empfängt.
Zitat von: Klaus0815 am 11 Januar 2016, 23:36:01
(Notfalls baue ich mir sonst noch mal einen zus. "anlern-Gateway"
Brauchst Du überhauptnicht, kanns bereits im Sketch die ID vergeben.
Bei mir funktioniert das anlernen auch ganz normal, allerdings NUR mit der version von hexenmeister, da der Sketch von mysensors.org mit FHEM nicht zurecht kommt
Bei mir läuft nun auch der Wifi-Gateway mit der Dev-Version (1.6.0-beta) seit dem Wochenende. Das Ganze ohne Anpassungen am Coding. Scheint so, als seien die Probleme mit den unterschiedlichen Längen der Integer (2/4 bytes) behoben. Nun muss ich nur noch die Stabilität meines Lux-Meters verbessern, der hängt sich so alle paar Stunden auf. Bei den Sensoren mit Temp/Hum, kombiniert mit Distanz zusammen mit Temp/Hum (zwecks Kompensation) und auch Binär-Switch (PIR) habe ich keine Probleme, die laufen auch seit dem Wochenende.
Mir gefällt das Projekt mysensors recht gut, einfache Komponenten, einfache Sketches, gute Community. Das sich das System mit seiner Offenheit kaum mit kommerziellen Produkten messen lassen kann, nehm ich in kauf. Dafür kann ich fast machen, was ich will. Oder kenn ihr einen Sensor zur Schneehöhenmessung, der für ein paar Dollar zu haben ist?
Ich habe auch schon andere Sensoren versucht, z.B. mit den Attiny's. Da sind die Sensoren noch viel stromsparender, jedoch auch dieses System hat seine Nachteile.
@MrTom
da ich auch die Probleme habe bei Analog werten bekomme ich die langen Zahlen, möchte ich das ebenfalls wie Du testen. Die Version 1.6.0 beta, ist das eine ältere Version IDE Arduino? Hast evtl. den link dazu?
Gruß
Er meint die MySensors Development (mittlerweile 2.0.0beta) Sketche.
Hat jemand zufällig eine Beispielintegration in FHEM für ein MySensor Device, welches Daten von FHEM an MySensor schickt?
Ich scheitere aktuell schon an einem einfachen RelayActuator.
Schau mal hier: http://forum.fhem.de/index.php/topic,47115.45.html
Es funktioniert bei mir jetzt alles. Es hat sich herausgestellt, dass die RX Leitung von meinem Raspberry zum Gateway irgendwie nicht funktioniert hat. Empfangen war also kein Problem, nur das Senden ging überhaupt nicht.
Hallo,
ich habe 2 Probleme
1.) einen DHT22 eingebunden. Leider wird die Temperatur in Fahrenheit angezeigt. Eine umstellung des Device auf config M führt nicht zum Erfolg. Habe den Standartsketch von MySensors genommen.
/**
* The MySensors Arduino library handles the wireless radio link and protocol
* between your home built sensors/actuators and HA controller of choice.
* The sensors forms a self healing radio network with optional repeaters. Each
* repeater and gateway builds a routing tables in EEPROM which keeps track of the
* network topology allowing messages to be routed to nodes.
*
* Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
* Copyright (C) 2013-2015 Sensnology AB
* Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors
*
* Documentation: http://www.mysensors.org
* Support Forum: http://forum.mysensors.org
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* version 2 as published by the Free Software Foundation.
*
*******************************
*
* REVISION HISTORY
* Version 1.0 - Henrik EKblad
*
* DESCRIPTION
* This sketch provides an example how to implement a humidity/temperature
* sensor using DHT11/DHT-22
* http://www.mysensors.org/build/humidity
*/
#include <SPI.h>
#include <MySensor.h>
#include <DHT.h>
#define CHILD_ID_HUM 0
#define CHILD_ID_TEMP 1
#define HUMIDITY_SENSOR_DIGITAL_PIN 3
unsigned long SLEEP_TIME = 30000; // Sleep time between reads (in milliseconds)
MySensor gw;
DHT dht;
float lastTemp;
float lastHum;
boolean metric = true;
MyMessage msgHum(CHILD_ID_HUM, V_HUM);
MyMessage msgTemp(CHILD_ID_TEMP, V_TEMP);
void setup()
{
gw.begin();
dht.setup(HUMIDITY_SENSOR_DIGITAL_PIN);
// Send the Sketch Version Information to the Gateway
gw.sendSketchInfo("Humidity", "1.0");
// Register all sensors to gw (they will be created as child devices)
gw.present(CHILD_ID_HUM, S_HUM);
gw.present(CHILD_ID_TEMP, S_TEMP);
metric = gw.getConfig().isMetric;
}
void loop()
{
delay(dht.getMinimumSamplingPeriod());
float temperature = dht.getTemperature();
if (isnan(temperature)) {
Serial.println("Failed reading temperature from DHT");
} else if (temperature != lastTemp) {
lastTemp = temperature;
if (!metric) {
temperature = dht.toFahrenheit(temperature);
}
gw.send(msgTemp.set(temperature, 1));
Serial.print("T: ");
Serial.println(temperature);
}
float humidity = dht.getHumidity();
if (isnan(humidity)) {
Serial.println("Failed reading humidity from DHT");
} else if (humidity != lastHum) {
lastHum = humidity;
gw.send(msgHum.set(humidity, 1));
Serial.print("H: ");
Serial.println(humidity);
}
gw.sleep(SLEEP_TIME); //sleep a bit
}
(http://up.picr.de/24486012la.jpg)
2.) DS18b20 ebenfalls mit Standartsketch Zeigt kein TempReading an. Auch meine Versuche einen anzulegen scheiterten.
/**
* The MySensors Arduino library handles the wireless radio link and protocol
* between your home built sensors/actuators and HA controller of choice.
* The sensors forms a self healing radio network with optional repeaters. Each
* repeater and gateway builds a routing tables in EEPROM which keeps track of the
* network topology allowing messages to be routed to nodes.
*
* Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
* Copyright (C) 2013-2015 Sensnology AB
* Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors
*
* Documentation: http://www.mysensors.org
* Support Forum: http://forum.mysensors.org
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* version 2 as published by the Free Software Foundation.
*
*******************************
*
* DESCRIPTION
*
* Example sketch showing how to send in DS1820B OneWire temperature readings back to the controller
* http://www.mysensors.org/build/temp
*/
#include <MySensor.h>
#include <SPI.h>
#include <DallasTemperature.h>
#include <OneWire.h>
#define COMPARE_TEMP 1 // Send temperature only if changed? 1 = Yes 0 = No
#define ONE_WIRE_BUS 3 // Pin where dallase sensor is connected
#define MAX_ATTACHED_DS18B20 16
unsigned long SLEEP_TIME = 30000; // Sleep time between reads (in milliseconds)
OneWire oneWire(ONE_WIRE_BUS); // Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs)
DallasTemperature sensors(&oneWire); // Pass the oneWire reference to Dallas Temperature.
MySensor gw;
float lastTemperature[MAX_ATTACHED_DS18B20];
int numSensors=0;
boolean receivedConfig = false;
boolean metric = true;
// Initialize temperature message
MyMessage msg(0,V_TEMP);
void setup()
{
// Startup up the OneWire library
sensors.begin();
// requestTemperatures() will not block current thread
sensors.setWaitForConversion(false);
// Startup and initialize MySensors library. Set callback for incoming messages.
gw.begin();
// Send the sketch version information to the gateway and Controller
gw.sendSketchInfo("Temperature Sensor", "1.1");
// Fetch the number of attached temperature sensors
numSensors = sensors.getDeviceCount();
// Present all sensors to controller
for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {
gw.present(i, S_TEMP);
}
}
void loop()
{
// Process incoming messages (like config from server)
gw.process();
// Fetch temperatures from Dallas sensors
sensors.requestTemperatures();
// query conversion time and sleep until conversion completed
int16_t conversionTime = sensors.millisToWaitForConversion(sensors.getResolution());
// sleep() call can be replaced by wait() call if node need to process incoming messages (or if node is repeater)
gw.sleep(conversionTime);
// Read temperatures and send them to controller
for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {
// Fetch and round temperature to one decimal
float temperature = static_cast<float>(static_cast<int>((gw.getConfig().isMetric?sensors.getTempCByIndex(i):sensors.getTempFByIndex(i)) * 10.)) / 10.;
// Only send data if temperature has changed and no error
#if COMPARE_TEMP == 1
if (lastTemperature[i] != temperature && temperature != -127.00 && temperature != 85.00) {
#else
if (temperature != -127.00 && temperature != 85.00) {
#endif
// Send in the new temperature
gw.send(msg.setSensor(i).set(temperature,1));
// Save new temperatures for next compare
lastTemperature[i]=temperature;
}
}
gw.sleep(SLEEP_TIME);
}
(http://up.picr.de/24486013qb.jpg)
habe eine SerialGateway
hoffe ihr könnt helfen
Hallo,
Zitat von: Jarnsen am 04 Februar 2016, 17:50:54
2.) DS18b20 ebenfalls mit Standartsketch Zeigt kein TempReading an. Auch meine Versuche einen anzulegen scheiterten.
Du kannst das mapReading-Attribut auch manuell anlegen.
attr Temp mapReading_T0 0 temperatureDas Reading sollte dann beim nächsten Update des Wertes erscheinen. Genau kannst Du bei weiteren Temperatursensoren an dem Device vorgehen.
VG
Sven
Zitat von: Jarnsen am 04 Februar 2016, 17:50:54
1.) einen DHT22 eingebunden. Leider wird die Temperatur in Fahrenheit angezeigt. Eine umstellung des Device auf config M führt nicht zum Erfolg. Habe den Standartsketch von MySensors genommen.
Versuch mal diese Zeile auszukommentieren.
Evtl. ist das Gateway auf Metric bzw. schickt das dem Sketch.
metric = gw.getConfig().isMetric;
Wenn das nicht geht nimm doch einfach die Umrechnung raus, wirst du eh nie brauchen.
Gruß,
Kuzl
@ Kuzl
// metric = gw.getConfig().isMetric;
das war die Lösung..
@ SvenJust
Danke für das Beispiel
attr Temp mapReading_T0 0 temperature
jetzt weiß ich zumindest wie ich mehrer TempSensoren an einem Device betreiben kann. Das war Allerdings nicht die Lösung bei mir. Die Lösung war ein Widerstand den ich vergessen hatte zwische VCC und D3. Hatte zwar keinen 4k7 zur Hand sondern nur 330Ohm aber der geht auch und das Reading wurde automatisch hinzugefügt.
Danke Jarnsen
hallo nochmal,
ich wollte jetzt ne Batterie prozentabfrage einrichten. Habe nen Block aus 4 x AAA in Reihe geschalten also ca 6V.
Jetzt habe ich gelesen GitHub (https://github.com/sweebee/Arduino-home-automation/tree/master/libraries/readVcc) und Pimatic (https://forum.pimatic.org/topic/457/mysensors-plugin-battery-level/4) das der Arduino mit ATHMEGA 328 intern die V misst. Ich habe den Sketch soweit angepasst und die Libary eingefügt. Leider bringts beim überprüfen immernoch Fehler.
/**
* The MySensors Arduino library handles the wireless radio link and protocol
* between your home built sensors/actuators and HA controller of choice.
* The sensors forms a self healing radio network with optional repeaters. Each
* repeater and gateway builds a routing tables in EEPROM which keeps track of the
* network topology allowing messages to be routed to nodes.
*
* Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
* Copyright (C) 2013-2015 Sensnology AB
* Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors
*
* Documentation: http://www.mysensors.org
* Support Forum: http://forum.mysensors.org
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* version 2 as published by the Free Software Foundation.
*
*******************************
*
* DESCRIPTION
*
* Example sketch showing how to send in DS1820B OneWire temperature readings back to the controller
* http://www.mysensors.org/build/temp
*/
#include <MySensor.h>
#include <SPI.h>
#include <DallasTemperature.h>
#include <OneWire.h>
#include <readVcc.h>
#define MIN_V
#define MAX_V
#define COMPARE_TEMP 1 // Send temperature only if changed? 1 = Yes 0 = No
#define ONE_WIRE_BUS 3 // Pin where dallase sensor is connected
#define MAX_ATTACHED_DS18B20 16
unsigned long SLEEP_TIME = 30000; // Sleep time between reads (in milliseconds)
OneWire oneWire(ONE_WIRE_BUS); // Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs)
DallasTemperature sensors(&oneWire); // Pass the oneWire reference to Dallas Temperature.
MySensor gw;
float lastTemperature[MAX_ATTACHED_DS18B20];
int numSensors=0;
boolean receivedConfig = false;
boolean metric = true;
// Initialize temperature message
MyMessage msg(0,V_TEMP);
void setup()
{
// Startup up the OneWire library
sensors.begin();
// requestTemperatures() will not block current thread
sensors.setWaitForConversion(false);
// Startup and initialize MySensors library. Set callback for incoming messages.
gw.begin();
// Send the sketch version information to the gateway and Controller
gw.sendSketchInfo("Temperature Sensor", "1.1");
// Fetch the number of attached temperature sensors
numSensors = sensors.getDeviceCount();
// Present all sensors to controller
for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {
gw.present(i, S_TEMP);
// Define voltages
int MIN_V = 2400; // empty voltage (0%)
int MAX_V = 6000; // full voltage (100%)
int oldBatteryPcnt;
}
}
void loop()
{
// Process incoming messages (like config from server)
gw.process();
// Fetch temperatures from Dallas sensors
sensors.requestTemperatures();
// query conversion time and sleep until conversion completed
int16_t conversionTime = sensors.millisToWaitForConversion(sensors.getResolution());
// sleep() call can be replaced by wait() call if node need to process incoming messages (or if node is repeater)
gw.sleep(conversionTime);
// Read temperatures and send them to controller
for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {
// Fetch and round temperature to one decimal
float temperature = static_cast<float>(static_cast<int>((gw.getConfig().isMetric?sensors.getTempCByIndex(i):sensors.getTempFByIndex(i)) * 10.)) / 10.;
// Only send data if temperature has changed and no error
#if COMPARE_TEMP == 1
if (lastTemperature[i] != temperature && temperature != -127.00 && temperature != 85.00) {
#else
if (temperature != -127.00 && temperature != 85.00) {
#endif
// Send in the new temperature
gw.send(msg.setSensor(i).set(temperature,1));
// Save new temperatures for next compare
lastTemperature[i]=temperature;
// Measure battery
float batteryV = readVcc();
int batteryPcnt = (((batteryV - MIN_V) / (MAX_V - MIN_V)) * 100 );
if (batteryPcnt > 100) {
batteryPcnt = 100;
if (batteryPcnt != oldBatteryPcnt) {
gw.sendBatteryLevel(batteryPcnt); // Send battery percentage
oldBatteryPcnt = batteryPcnt;
}
}
}
}
gw.sleep(SLEEP_TIME);
}
ich hoffe mal wieder auf eure Hilfe, Gruß Jarnsen
Welche Fehlermeldung erhälst du denn?
Hallo,
Ich lese mich gerade auch zu dem Thema mySensors ein, und zuerst will ich mit das Gateway bauen.
Ich bevorzuge das LAN Gateway, wobei der NodeMCU auch interessant ist, aber schwer zu bekommen.
Oder hat da jemand eine Bezugsquelle?
Meine Frage zum nrf24l01+ ist, da dies ja mit 3 - 3,6V betrieben werden kann ist ja für den Nano oder UNO oder Mega ja kein Problem.
Weiter unten steht im Datenblatt VIH = max 5.25V, VIL = 0.3V VDD, VOH = VDD (3,3V), VOL = 0.3V
Bei VOH frage ich mich nun ob man zwischen Nano/Uno nicht doch ein Level Shifting dazwischen dem nrf24l01+ machen sollte ???
Dann sieht man öfters NRF24L01 + PA + LNA und es sind 2 ICs auf der Platine, mit Antennenanschluss.
Ein Antennenanschluss würde ich ja bevorzugen, aber warum sind da 2ICs drauf?
http://www.dx.com/p/nrf24l01-pa-lna-wireless-module-w-antenna-black-3-0-3-6v-222913#.VsSP6WeFNoI
Als Netzwerk wollte ich dann ein W5100 nehmen.
Spricht da was dagegen?
Und wenn ich ein nrf24l01+ mit dem Arduino Mini verbinden möchte brauche ich wohl sowas hier ? Damit 5V > 3.3V
http://www.dx.com/p/socket-adapter-plate-board-converter-8-pin-nrf24l01-wireless-transceive-module-for-51-car-kit-etc-421945#.VsSNO2eFNoI
Hallo,
ich habe aktuell 2 FHEM Instanzen und teste z.Zt. mit mehreren Gateways.
Ein Sensor hat ja nur ein IODevice. Das führt dazu, dass das davon nicht betroffene Gateway laufend Meldungen ausgibt wie
MYSENSORS: ignoring set-msg from unknown radioId 104, childId 4 for V_HUM
Die schreiben mir das Log voll und machen alles etwas unübersichtlich.
Ich wünsche ;D ;D mir an dieser Stelle ein Attribut beim Gateway, dass Messages vom Sensor (Sensoren) gezielt ignoriert werden können, z.B. sowas wie
attr <gateway> ignoreRadioIDs 103,104
Das hätte den Vorteil, dass Meldungen von unbekannten Sensoren weiterhin im Log landen, bei bekannten Sensoren aber unterdrückt werden.
Leider kann ich das nicht selber umsetzen aber vielleicht findet die Idee ja ein paar Unterstützer.
Danke
Holger
Warum sollte man das geziehlt ignorieren? Ober andersrum gefragt: Was hat man davon, dass nicht geziehlt ignorierte messages dann doch geloggt werden?
Alle unbekannten Devices kann man heute schon ignorieren - setze dafür einfach am gateway das Attribut 'verbose' auf 2.
Ansonsten wäre es natürlich sinnvoller die Gateways (und die Ihnen zugeordneten Sensoren) auf unterschiedlichen Funkkanälen laufen zu lassen. Geht leider nicht über ein Fhem-attribut, das muss man vor dem Flashen in der MySensors-library im Sourcecode (https://github.com/mysensors/Arduino/blob/development/libraries/MySensors/MyConfig.h#L372)konfigurieren
@Norbert Du hast noch nen offenen PR auf Github 8)
Zitat
Was hat man davon, dass nicht geziehlt ignorierte messages dann doch geloggt werden?
zB wenn ich einen weiteren Sensor einbringe, sollen die Gateways das auch melden. Oder falls ein Nachbar auch mit MySensors experimentiert, wäre es schön, solche Informationen erhalten zu können. Da könnte man sich z.B. über ClientIDs einigen, um eine Vergabe der gleichen IDs vermeiden zu können.
Mit verbose 2 schließe ich das alles aus. Da ich auch nicht weiß, welche Meldungen noch mit verbose 3 kommen können (außer den ignore Meldungen), erscheint es mir sinnvoll, Meldungen gezielt über ein Attribut beeinflussen zu können.
Momentan experimentiere ich mit 4 Gateways (WLAN) in 2 FHEM-Instanzen und zusammen jetzt 4 Sensorplatinen. Bei den Sensoren frage ich T, H und 2 x Buttons ab. Evtl. werde ich auch noch ein LAN-Modul testen. Und gerade zum Testen möchte man ja grundsätzlich Meldungen erhalten (daher würde ich bei den Gateways lieber bei verbose 3 bleiben wollen). Allerdings kommen auf diese Art jede Menge Meldungen zusammen, die mir ansonsten das Log so zuschreiben, dass evtl. wichtige Meldungen dabei untergehen.
Der gleiche Funkkanal bietet mir den Vorteil – gerade beim Testen – einen Sensor schnell auf ein anderes Gateway umzulegen, falls es irgendwo klemmt. Ansonsten müsste immer der Chip neu programmiert werden, das finde ich dann doch etwas unglücklich.
LG
Holger
Ich habe jetzt mal MySensors mit Temperatursensoren (DS18B20, Sketch DallasTemperatureSensor.ino ) experimentiert.
Gibt es hier eine Möglichkeit, nicht nur die Temperatur anzuzeigen sondern auch die Hex-Adresse des dazugehörigen Sensors? Ansonsten hat man ja nur die Info: temperature, temperature1, temperature2, ...
Von welchem Sensor die Temperatur kommt, ist nicht zu sehen. Das kann man zwar ausprobieren, ist aber mühsam. Und wie groß ist die Gefahr, dass beim nächsten Start evtl. Zuordnungen geändert sind?
Hat da schon einer Erfahrungen gesammelt und möglichst sogar eine Lösung dazu?
LG
Holger
Du könntest mal im MySensors-forum nachfragen, was Die davon halten. Ich fände es gar nicht verkehrt, wenn Sensoren standardmäßig eine eindeutige ID ähnlich einer Mac-addresse oder 1-Wire-ids hätten. Kann man in eigene Sensorsketche natürlich problemlos selber mit reinbasteln und im FHEM auch durch manuelles anlegen der nötigen set/mapReading-attribute aktivieren, aber ich nehme das nicht in die Liste der Standardreadings von Sensoren mit auf, wenn es nicht 'offiziell' (also auf Mysensors.org) so beschlossen wurde. Zum Verständniss: die Standardreadings erzeugen beim Autocreate die set/mapReading-attribute, die die MySensors-Werte auf FHEM-readings abbilden. Das kann man jederzeit auch selber von Hand tun. Wenn das Device erst mal fertig angelegt ist, haben die StandardReadings keine weitere Bedeutung mehr.
Gruß,
Norbert
Danke für's Feedback.
Zitat
Kann man in eigene Sensorsketche natürlich problemlos selber mit reinbasteln und im FHEM auch durch manuelles anlegen der nötigen set/mapReading-attribute aktivieren
Leider ist mir überhaupt nicht klar, wie ich das angehen kann. Hast du evtl. ein Beispiel oder ähnliches, mit dem ich vielleicht etwas mehr Verständnis des Ganzen erreichen kann?
LG
Holger
Und schon kommt meine nächste Frage / Anmerkung...
Ich kämpfe momentan mit 2 Gateways, die relativ häufig einen Reset auslösen. Nach dem Rest wird die WLAN-Verbindung aber gleich wieder aufgebaut. Duch den Reset verliert aber auch FHEM die Verbindung. Leider erkennt FHEM nicht, dass das Gateway nach kurzem aber wieder zur Verfügung steht. Erst nach einem gezielten
set <gateway> connect
wird die Verbindung wieder aufgebaut.
Nun kenne ich nicht die Möglichkeiten, inwiefern das Gateway einen solchen Zusammenhang selber erkennen kann. Hilfreich wäre es aber zumindest, wenn das Gateway ein Reading mit dem Zeitstempel der letzten verarbeiteten Meldung hätte (das Gateway selber sieht ja die Meldungen aller Sensoren (zumindest bei gleichen Kanälen)). Darauf könnte man dann einen Watchdog ansetzen und bei längerem Ausbleiben von Meldungen ein connect durchführen.
Man kann natürlich auch auf ausbleibende Meldungen vom Sensor prüfen, das halte ich aber für nicht so effektiv, da – abhängig vom Sensortyp – auch große Pausen realistisch sind. Einen Ausfall würde man beim Gateway viel früher bemerken können.
LG
Holger
Zitat von: Omega am 23 Februar 2016, 11:47:24
Nun kenne ich nicht die Möglichkeiten, inwiefern das Gateway einen solchen Zusammenhang selber erkennen kann. Hilfreich wäre es aber zumindest, wenn das Gateway ein Reading mit dem Zeitstempel der letzten verarbeiteten Meldung hätte (das Gateway selber sieht ja die Meldungen aller Sensoren (zumindest bei gleichen Kanälen)). Darauf könnte man dann einen Watchdog ansetzen und bei längerem Ausbleiben von Meldungen ein connect durchführen.
Oder du machst einfach jede Minute vorsorglich ein Connect. Nicht die feine englische Art, funktioniert aber. habe mit meinem LAN-Gateway auch so am Laufen (auch wegen gelegentlichen Resets).
Bei Temperaturen könnte man das wohl machen. Ich möchte aber auch die Impulse beim Gaszähler auswerten. Bei einem minütlichen connect befürchte ich doch, viele Impulse zu übersehen aufgrund des dauernden reconnects.
Hallo,
Zitat von: Omega am 22 Februar 2016, 17:53:39
Gibt es hier eine Möglichkeit, nicht nur die Temperatur anzuzeigen sondern auch die Hex-Adresse des dazugehörigen Sensors? Ansonsten hat man ja nur die Info: temperature, temperature1, temperature2, ...
In der API von MYSENSORS ist dafür ab Version 1.5 eine Message mit dem folgenden Subtype vorgesehen:
V_ID 42 Optional unique sensor id (e.g. OneWire DS1820b ids) S_TEMPQuelle: https://www.mysensors.org/download/serial_api_15#message-structure-elements
Ich will das hier im Moment nicht testen, da ich noch mit 1.4.2 arbeite.
VG
Sven
Danke für die Info.
Wenn ich das richtig verstehe, ist das V_ID da, um die Meldung entsprechend auszugeben. Schwieriger wird es für mich, erst einmal die jeweiligen IDs der 1wire-Sensoren auszulesen.
Aus dem MySensors-Forum habe ich mittlerweile die Info, dass unter den Arduino Beispielen (Datei-Beispiele-DallasTemperature-Multiple) ein Sketch ist, in dem die IDs ausgelesen werden.
Jetzt "darf" ich dann mal versuchen, dass auf MySensors abzubilden. Vielleicht bekomme ich es ja hin - mal sehen.
LG
Holger
Hallo Holger, wenn ich morgen mal ein paar Minuten Zeit habe versuche ich einen Sketch zu bauen. Möchte auch bald mehrere Temperatur Sensoren an einem Sensor Gängen und dann macht die ID natürlich schon Sinn.
Edit: hast du mir den Link zum Thema?
Link habe ich: http://forum.mysensors.org/topic/3214/1wire-missing-unique-ids-28-xxxxxxxxxxxx/3
steht aber auch nicht mehr drin...
Finde ich natürlich super, wenn du die Zeit finden solltest ;D ;D
Meine Sketch-Fähigkeiten sind doch noch ziemlich rudimentär.
Im Heizungskeller habe ich derzeit 13 1wire-Sensoren, die am GPIO eines Raspi hängen. Den will ich eigentlich mittelfristig entlasten durch MySensors. Ohne einen Zusammenhang zwischen eindeutiger ID und der dazugehörigen Temperatur mache ich den Schritt aber nicht. Wäre mir zu unsicher.
An dem genau gleichen Punkt bin ich auch gerade. Mehrere Sensoren am Raspberry welcher einem MySensor weichen soll. Bin gerade dabei mir die Sketch genauer anzuschauen leider kann ich gerade nicht paralell testen.
Edit: Habe mal einen ersten Prototypen fertig, erstmal nur für den Serieller Output aber das ist schon mal wichtig, wenn das geht, dann muss es nur gesendet werden ;)
Prototyp war soweit erfolgreich. Bei Gelegenheit baue ich die mySensor und FHEM Funktion ein. Dann brauche ich weitere Tester.
Da bin ich dabei.
Welche Lib-Version verwendest du?
Hallo zusammen,
endlich kann ich (glaube/hoffe ich zumindest) auch mal was sinnvolles zu den vielen tollen Lösungen hier beitragen...
In diesem Sinne also erst mal Danke an alle, die sich hier mit einbringen!!!!!
Über das Problem der sicheren Zuordnung von DS18B20 bin ich neulich auch gestolpert. Es gibt da einen Beispielsketch auf Mysensors.org (http://forum.mysensors.org/topic/2607/video-how-to-monitor-your-refrigerator), der mit einem Array arbeitet. Auf der Basis hab ich mir was für die Heizungsüberwachung gebastelt, Ergebnis in der aktuellen Fassung anbei. Ist zwar bei weitem nicht fertig, funktioniert aber zumindest, was die eindeutige Übermittlung der Temperaturwerte angeht (jedenfalls seit mehr als 2 Wochen mit sehr vielen reboots).
Eigentlich verstehe ich nichts vom Programmieren :-\, daher entschuldigt bitte das Durcheinander im Code!
Basis: Arduino IDE 1.6.7, Mysensors 2.0.0-beta. ACHTUNG: Die Dallas-Libs über die IDE NICHT aktualisieren! (Jedenfalls gibt es neuere Versionen, die nicht funktionieren, kann nicht sagen, ob das zwischenzeitlich wieder behoben ist.)
Hoffe, das hilft jemandem,
Jörg
Hallo Jörg, danke für deinen Beispielcode. Leider ist dieser Code halt statisch und muss für jeden Temperatur-Sensor angepasst werden. Ich finde den Sketch sehr interessant, kannst du uns mehr zum Aufbau / den Hintergründen erzählen?
PS: Mein Sketch soll on the fly die DS18B20 ID zusammen mit den Temperaturen ausgeben, leider hatte ich dieses WE keine Zeit daran zu arbeiten.
PS: Seit heute sollte es in FHEM ein kleines MySensors-Update geben. Danach sollten auch die ganzen Sketches, welche Informationen von FHEM erhalten, funktionieren.
Neugierde wird bestraft. Nach dem Update habe ich folgende Fehlermeldungen:
Messages collected while initializing FHEM:
configfile: Cannot load module MYSENSORS_DEVICE
Cannot load module MYSENSORS_DEVICE
Cannot load module MYSENSORS_DEVICE
Cannot load module MYSENSORS_DEVICE
Cannot load module MYSENSORS_DEVICE
Cannot load module MYSENSORS_DEVICE
und meine ganzen Definitionen der Sensoren sind nicht mehr vorhanden bzw. werden nicht mehr angezeigt.
Die Gateways sind aber noch alle da.
Zitat von: Omega am 29 Februar 2016, 10:32:08
Neugierde wird bestraft. Nach dem Update habe ich folgende Fehlermeldungen:
Messages collected while initializing FHEM:
configfile: Cannot load module MYSENSORS_DEVICE
Cannot load module MYSENSORS_DEVICE
Cannot load module MYSENSORS_DEVICE
Cannot load module MYSENSORS_DEVICE
Cannot load module MYSENSORS_DEVICE
Cannot load module MYSENSORS_DEVICE
und meine ganzen Definitionen der Sensoren sind nicht mehr vorhanden bzw. werden nicht mehr angezeigt.
Die Gateways sind aber noch alle da.
Dito, bei mir auch das gleiche :(
Danke für das leider schlechte Feedback. Jedoch kann ich mir bisher keinen Reim bilden, wieso die Fehlermeldungen erscheinen. Ich schaue es mir mit Norbert an.
Ansonsten hier solange die alte Version:
https://raw.githubusercontent.com/Kolbi/fhem-mirror/37a5dcf89463c5b686a09bedcc9e46f4cfc9621f/fhem/FHEM/lib/Device/MySensors/Constants.pm
https://raw.githubusercontent.com/Kolbi/fhem-mirror/5f5b0751364324f6475093fb038c2843569f4807/fhem/FHEM/10_MYSENSORS_DEVICE.pm
Hallo zusammen,
bei mir das gleiche Verhalten: nach Update alle MySensor Definitionen weg und etliche Fehlermeldungen. Dies erschien im Log nach dem ersten Neustart nach Update:
2016.02.29 09:33:44 1: reload: Error:Modul 10_MYSENSORS_DEVICE deactivated:
Bareword "VAR1" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 86, <$fh> line 1985.
2016.02.29 09:33:44 0: Bareword "VAR1" not allowed while "strict subs" in use at ./FHEM/10_MYSENSORS_DEVICE.pm line 86, <$fh> line 1985.
Ein update force in der ersten Verzweiflung brachte auch nichts. Das Modul 10_MYSENSORS_DEVICE wird nicht geladen, ergo fliegen die ganzen Devices raus und interaktionen erzeugen Fehlermeldungen.
Habe dann 10_MYSENSORS_DEVICE, 00_MYSENSORS und die fhem.cfg vom Backup davor zurückgespielt und alles läuft wieder.
Vielleicht hilft das bei der Fehlerbeseitigung.
Viele Grüße
schreib mal in der 10_MYSENSORS_DEVICE.pm in Zeile 100 vor das VAR1 ein 'V_'.
Also statt:
S_POWER => { receives => [V_VAR1], sends => [V_WATT,V_KWH,VAR1] }, # Power measuring device, like power meters
richtig:
S_POWER => { receives => [V_VAR1], sends => [V_WATT,V_KWH,V_VAR1] }, # Power measuring device, like power meters
@Hauswart: testest Du Deine Patches eigentlich, bevor Du sie submittest? ;)
gleiches Problem hier.
configfile: Cannot load module MYSENSORS_DEVICE
Cannot load module MYSENSORS_DEVICE
Zitat von: ntruchsess am 29 Februar 2016, 11:40:56
@Hauswart: testest Du Deine Patches eigentlich, bevor Du sie submittest? ;)
Eigentlich ja, verstehe auch nicht wie mir dieser Fehler durch die Lappen gegangen sein konnte. :)
Diese Version sollte funktionieren: https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/10_MYSENSORS_DEVICE.pm - kann sie leider nur gerade nicht selbst testen... :/
ich kann es auch erst heute abend ins SVN übernehmen...
Hallo Hauswart,
Danke für die Rückmeldung; das mit der direkten Rückmeldung der Sensoradresse an FHEM wäre toll, das würde einiges erleichtern, wie überhaupt die Möglichkeit, zwischen Sensoren und FHEM Infos hin- und herzuschieben (s.u.). Auch für mein Problem würde es manches erleichtern. So habe ich manche Schwellenwerte direkt einprogrammiert und muß jedes mal wieder den Arduino wechseln, wenn ich was neues ausprobieren möchte...
Der Sketch soll etwas intelligenter sein, als eine "normale" Sensor-Node. Generell geht es um Infos und Aktionen rund um meine Therme, die zudem leider nach dem Wechsel der Fenster etwas überdimensioniert ist.
Es hängen dran:
- 5 DS-Temp-Sensoren (Ziel: Ablösung des 1-W-USB-Controllers, also noch drei)
- Gaszähler
- Ein Relay
- Ein Servo
Soweit erklärungsbedürftig:
- Mit dem Relay schalte ich meine Zirkulationspumpe fürs Warmwasser ein bzw. aus. Zum einen über FHEM (zeitgesteuert mit Urlaubsfunktion usw.), zum anderen prüfe ich kurzzyklisch, ob die WW-Temperatur schnell gestiegen ist, was dann als WW-Anforderung gedeutet wird. Habe ich dann wieder WW an der Pumpe (also im Rückfluß), kann die Pumpe auch wieder ausgeschaltet werden; FHEM bekommt dann jeweils nur die Info, was der Stand der Dinge ist...
- Mit dem Servo kann ich die intern verbaute Zirkulationspumpe umschalten. Die ist 3-stufig, wobei ich festgestellt habe, dass es für die "normale" Heizfunktion in der Regel besser ist, sie so weit als möglich zu drosseln, dann moduliert die Therme besser und geht nicht dauern ein und aus. Nur die Heizkurve anzupassen war jedenfalls insoweit nicht hinreichend.
Als FHEM-ler will man aber nicht immer in den Keller, wenn sich das Wetter ändert, um die Abdeckung der Therme abzuschrauben und so einen doofen Regler wieder umzustellen, daher die Idee mit dem Servomotor am Regler :-*. Das war/ist zunächst nur außentemperaturabhängig über FHEM.
Nachdem das soweit funktioniert hatte, habe ich allerdings festgestellt, dass ein häufigeres Umschalten jedenfalls dann Sinn zu machen scheint, wenn ich WW mache. Sonst kommen sich Heizen und WW-Bereitung in die Quere. Von daher wäre es das nächste Ziel, auch automatisiert auf die diesbezüglichen Rahmenbedingungen zu reagieren. Das verbirgt sich hinter dem auskommentierten Teil. Da das aber WAF-sensibel ist und ich besser auch länger vor Ort bin (=WE), bin ich da noch nicht recht weitergekommen.
Da wäre auch der "Rückkanal" hilfreich, denn statt selbst schalten, könnte der Arduino auch melden: Hey FHEM, ich denke es wäre jetzt sinnvoll, Stufe x zu schalten und dann auf die Reaktion zu warten.
Hoffe, das ist nachvollziehbar,
Jörg
Habe die von Hauswart 3 Posts oberhalb bereitgestellte 10_MYSENSORS_DEVICE.pm mal ausprobiert: funktioniert wie gewünscht.
Ein neuer Sensor, der eine S_CUSTOM Definition hat, wird erkannt und alle 5 Variablen V_VAR1...5 als setreadings eingebaut.
fixed (https://sourceforge.net/p/fhem/code/10967/)
Ihr könnt wieder regulär updaten...
Ich fände es gut, wenn in den Internals der Devices nicht nur die "radioId" aufgeführt wird sondern auch noch der verwendete Kanal (festgelegt durch #define MY_RF24_CHANNEL 83). Das wäre hilfreich beim Fehler suchen, falls man mehrere Gateways mit unterschiedlichen Kanälen verwendet zusammen mit Sensoren, die zwar denselben Sketch enthalten, aber mit unterschiedlichen Kanälen verwendet werden.
LG
Holger
Ich habe einen Arduino Nano mit dem Sketch fürs Serial Gateway von mysensors.org bespielt und in Fhem folgerndermaßen eingebunden:
Internals:
DEF /dev/ttyUSB0
DeviceName /dev/ttyUSB0
FD 45
NAME mySensorsIO
NOTIFYDEV global
NR 145
NTFY_ORDER 50-mySensorsIO
PARTIAL �+�:���1���Q�a��Ea<�)za�zِl`�q˴aZ-zq��|y9jh�x���ِ% ��iq]��&ޟِlz��iy��|izny��y8勔A��
STATE connected
TYPE MYSENSORS
ack 0
inclusion-mode 1
outstandingAck 0
Readings:
2016-03-09 13:18:19 connection connected
2016-03-09 13:18:19 state opened
Attributes:
room IOs
stateFormat connection
Auf einem zweiten Nano hab ich das Sketch für den DHT22 Luftfeuchte aufgespielt. Wenn ich das richtig verstanden habe, dann müsste ich, wenn ich den inclusion-mode aktiviere und den Luftfeuchtigkeitsnano resete automatisch den Sensor in FHEM eingebunden haben? Leider tut sich absolut garnichts.
Das attribut autocreate ändert ebenfalls nichts.
Am Seriellen Monitor des Luftfeuchtigkeitsskechtes bekomme ich allerdings auch merkwürdige ausgaben:
(áÔ®X´%)°&øÌ/ôƒ¡Ð|2:&OAZ,8§{Z¹r|aXè˜X
Was kann da falsch laufen?
Beste Grüße
Fabian
Hallo Fabian,
als relativer Mysensors- und Arduino-Neuling würde ich auf einen Fehler beim Flashen des Arduino tippen. Ich hatte auch gelegentlich ähnliche Effekte bei meinen ersten Geh-Versuchen. An sich sollte der Sensor lesbaren Text auf die Konsole bringen, zumindest wenn Du einen der Beispiel-Sketche verwendet hast.
Ich würde also als erstes nochmal probieren, den Sketch neu hochzuladen. Sofern das (noch) nichts bringt, könntest Du für die Fehlersuche zusätzlich noch eine reine Repeater-Node zusammenstöpseln. Damit läßt sich die Funktionalität des GW testen und dessen Zusammenspiel mit fhem. Der Repeater sollte wie von Dir beschrieben automatisch angelegt werden. Über dessen serielle Konsole kannst Du dann sehen, was Dein Feuchtesensor so funkt.
Bei mir war auch die recht geringe Funk-Reichweite der ersten meiner Modelle ein Problem, allerdings hatte ich es gleich mit 2 Stockwerksdecken probiert. Das wurde erst nach einen Austausch auf verstärkte Nordics mit Antenne besser (evtl. hätten es auch zwei Stück angelöteter Draht getan)...
Viel Erfolg!
Jörg
Unter Win 10 x64 mit Arduino 1.6.7 geflasht. Ausgestetst hab ich zwei verschiedene Nano China Clones und einen Arduino Mega.
Auf dem Seriellen Monitor bekomm ich auch mit angeschlossenem DHT22 keine lesbaren Nachrichten.
Liegt das irgendwie an Win 10 ? Arduino ist x86. Ich nehm an, wenn ich auf dem seriellen monitor nichts lesbares bekomm werd ich auch in FHEM nichts sinnvolles hinbekommen. Ich hab aber keine Ahnung woran das liegen könnte. Arduino IDE meldet immer erfolgreich hochgeladen
Beste Grüße
Fabian
Hallo Fabian,
Welche geschwindigkeit hast du beim seriellen Monitor eingetragen, bzw. entspricht diese dem Eintrag in der MyConfig.h?
Sent from my iPad using Tapatalk
Danke!! Die Baudrate hatte ich überhaupt nicht angegeben - jetzt funktioniert alles ;D
Allerdings nur solange ich nur einen Sensor verwende. Ich dachte, die Sensorid wird dynamisch vergeben? Ich bekomme immer die id=11. Muss ich die ID irgenwo manuell vergeben? Ich hab die MySensorSketches bisher nicht verändert.
Hatte gerade das gleiche Problem.
Du musst die serielle Schnittstelle auf die richtige Geschwindigkeit einstellen, mit einem @115200 direkt ohne Leerzeichen an der Portbezeichnung:
define gateway MYSENSORS /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A700CVWE-if00-port0@115200
Ich hätte da mal ein komisches Problem anzubieten ich habe mit der MySensors Entwicklungsversion einen 18B20 Temperatursensor direkt am Seriellen Gateway angeschlossen aber im Gegensatz zu anderen Sensoren kann ich diesen in FHEM nicht auslesen oder verarbeiten obwohl er scheinbar richtig im Logfile des Gateway erscheint was mache ich falsch ?
2016.03.14 19:34:38 5: MYSENSORS Read: Rx: fr=000 ci=000 c=001(C_SET ) st=000(V_TEMP ) ack=0 '5.6'
Gruß Alex
Wie ist bei euch die Reichweite eines Batteriebetriebenen MySensors?
ProMini 3.3V und sowohl Sender als auch Empfänger mit der Antenne auf dem NRF24L01+.
Ich hab einen 4.7uF Kondensator zwischen VCC und GND am NRF angelötet und die Reichweite im Batteriebetrieb ist weniger als 5m. Bei einem Nano mit USB-Stromversorgung dagegen deutlich besser.
Gemessen wird Luftdruck und Temperatur mit einem DHT22. Da der DHT22 mit der Spannung der Batterie keine korrekten Werte geliefert hat hab ich einen StepUp zwischengeschaltet.
Ist es eigentlicht möglich/sinnvoll den DHT nicht über VCC mit Strom zu versorgen sondern über einen Pin den man nur während der Messung auf high stellt?
Grüße
Fabian
Reichweite mit Batterie gleiche Funkmodule also mit Antennen auf der Platine: mind. 6m und durch die Wand...
Geht vermutlich weiter, habe nur noch nicht getestet bzw. war noch kein Anwendungsfall die Reichweite zu messen...
Habe allerdings (noch) gleich ein StepUp/Down-Modul auf 3.3V (hatte ich mal für ESP8266 besorgt aber ESP8266 wg. zu hohem Batterieverbrauch wieder verworfen) und daran dann den "mySensor" hängen.
Sensor nur mit Strom versorgen, wenn er benötigt wird verlängert die Lebensdauer der Batterie (werde ich auch noch tun).
Ob das direkt über einen Out des Arduino geht hängt vom Stromverbrauch des Sensors ab.
Ansonsten per Transistor/FET schalten.
Gruß, Joachim
Reichweite ist bei mir viiieeele Meter ;D mit den Standart Antennen auf den NRF Platinen.
Am Gateway habe ich eine mit externer Antenne und ich empfange sogar die Fenstersensoren, welche im bei mir im Keller sind.
Also durch die Decke 1.OG dann durch den Raum EG und deren Decke (massive Betondecke/Boden) dann weiter in den Keller.
Das hätte ich auch nicht für möglich gehalten :-)
Ich denke darüber nach, mein Gateway noch mit den großen Modul auszustatten, somit (hoffe ich) könnte ich ebtl. sogar den Garten abdecken ohne das ich ein Repeater benötige.
Gruß Jens
Zitat von: alex0469 am 14 März 2016, 20:32:22
Ich hätte da mal ein komisches Problem anzubieten ich habe mit der MySensors Entwicklungsversion einen 18B20 Temperatursensor direkt am Seriellen Gateway angeschlossen aber im Gegensatz zu anderen Sensoren kann ich diesen in FHEM nicht auslesen oder verarbeiten obwohl er scheinbar richtig im Logfile des Gateway erscheint was mache ich falsch ?
2016.03.14 19:34:38 5: MYSENSORS Read: Rx: fr=000 ci=000 c=001(C_SET ) st=000(V_TEMP ) ack=0 '5.6'
Gruß Alex
Hallo Alex,
soweit ich weis kann ein Gateway nur als Gateway dienen.
Am Gateway können keine Sensoren oder Aktoren betrieben werden.
Gruß
Flo
Ich bekomme mit requestTime aktuell eine Zeit 2h früher gesendet als es aktuell ist (Node empfängt 20:00, obwohl es schon 22:00 ist). Sieht irgendwie nach Zeitzone und DST aus...
FHEM auf dem Raspi arbeitet mit der richtigen Zeit. Kann man das auf FHEM Seite korrigieren?
Richtig erkannt, das Gateway arbeitet mit UTC. Du musst im Arduino-Sketch die gewünschte Zeitzone einstellen.
schau mal hier:
http://playground.arduino.cc/Code/Time (http://playground.arduino.cc/Code/Time) (Update beachten!)
und hier
https://github.com/JChristensen/Timezone (https://github.com/JChristensen/Timezone)
In den Libaries sind Beispiele, damit sollte es Dir möglich sein, die richtige Zeit zu errechnen.
Ok, alles klar.
Aber gibt es einen Grund für UTC?
mysensors API (1.5)
ZitatI_TIME 1 Sensors can request the current time from the Controller using this message. The time will be reported as the seconds since 1970
Das ist wohl Unix-Zeit, die meisten Rechnersysteme verwenden diese:
ZitatWhat is epoch time?
The Unix epoch (or Unix time or POSIX time or Unix timestamp) is the number of seconds that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap seconds (in ISO 8601: 1970-01-01T00:00:00Z).
(stammt von http://www.epochconverter.com/ (http://www.epochconverter.com/))
Grund für UTC: da mußt Du Torvalds fragen ;)
Dein fhem wird wohl auf einem Linux laufen, das arbeitet mit UTC und Zeitzone (Windows übrigens auch). Wenn Du mit einem Zeitserver synchronisierst wird die interne Linux-Uhr auch auf UTC gestellt, über die eingestellte Zeitzone bekommst Du dann lokale Zeit angeziegt (desktop oder date)
Mit der Timezone libary klappt dann auch der Winter/Sommerzeit wechsel ganz von alleine, eben erst erfolgreich durchgeführt.
Gruß
Zitat von: Hauswart am 29 Februar 2016, 09:05:24
Hallo Jörg, danke für deinen Beispielcode. Leider ist dieser Code halt statisch und muss für jeden Temperatur-Sensor angepasst werden. Ich finde den Sketch sehr interessant, kannst du uns mehr zum Aufbau / den Hintergründen erzählen?
PS: Mein Sketch soll on the fly die DS18B20 ID zusammen mit den Temperaturen ausgeben, leider hatte ich dieses WE keine Zeit daran zu arbeiten.
So hier mal eine erste Testversion: https://github.com/Kolbi/MySensors/blob/master/DallasTemperatureSensor_with_ID.ino (https://github.com/Kolbi/MySensors/blob/master/DallasTemperatureSensor_with_ID.ino)
Funktioniert soweit eigentlich auch schon, nur ist mir derzeit noch nicht klar, wie ich es in FHEM verarbeite bzw. nach IDs trenne?
Nachtrag:
Bitte beim entsprechenden Device (autocreate) folgendes eingeben:
attr MYSENSOR_104 userreading mapReading_id 0 idLeider muss man derzeit die ID-Readings (noch) von Hand anlegen. Das Problem ist leider, dass die Beziehung Reading <=> Sensor nicht immer identisch ist, sondern variiert.
Hallo Hauswart,
das mit der eindeutigen Zuordnung der einzelnen Sensoren ist echt eine harte Nuss; ich habe damals die Lösung über das Array gewählt, weil ich keine Möglichkeit gesehen habe, auf andere Weise sicherzustellen, dass der von FHEM "gesehene" Wert auch zum "richtigen" Sensor paßt.
Nachdem ich jetzt gestern noch einige Tests gemacht habe und meine damalige Link-Liste durchgesehen habe, folgende Gedanken:
- Zuordnung innerhalb FHEM:
Hier scheint FHEM derzeit mit anderen Infos außer der Temperatur nichts anfangen zu können. Jedenfalls konnte ich auch bei mir die in Deinem Code nach jeder Messung übermittelte ID nirgendwo wiederfinden. Dann habe ich noch versucht, das im Rahmen der Presentation mögliche Kommentarfeld zu nutzen (nicht mal ein fester Text-String war in FHEM wiederzufinden, und einen Char* aus der Adresse machen, ist auch nicht so einfach...).
Aber vielleicht gibt es eine einfache Möglichkeit, das in das MYSENSORS-DEVICE-FHEM-Modul mit reinzubasteln (dann bliebe neben der Formatumwandlung "nur" noch die Frage, wie man das Kommentarfeld auswertbar macht; hier könnte man vielleicht aber auch den Reading-Namen auf den übermittelten Kommentar ändern, wenn ein solcher vorhanden ist; was ja nicht alle für Mysensors denkbaren Temperatursensoren erforderlich ist bzw. Sinn macht)
- Zuordnung auf der Arduino-Seite:
Hier kann man im Standard-Sketch m.E. nie sicher sein, ob sich die interne Nummerierung geändert hat, wenn "irgendwas" passiert (vom einfachen Reboot über den Ausfall einzelner Sensoren oder das Anklemmen neuer usw.).
Eine Lösung dazu wäre die mit dem starren Array, was aber erfordert, dass man vorher mühsam die Adressen ausliest und dann bei der Montage noch weiß, welche Adresse zu welchem der Kabel gehört. Umständlich eben.
Hier hat LeoDesigner einen interessanten Ansatz gewählt, nämlich dynamisch ein Array zu bilden und im EEPROM zu speichern. Das dürfte andere Nachteile haben, macht es aber dahingehend einfach, dass man "nur" jeweils die Sensoren einen nach dem anderen anschließt und den Arduino jeweils zwischendurch neu startet. Den entsprechenden Sketch (nicht getestet) gibt es unter https://github.com/leodesigner/mysensors-arduino/blob/master/DallasTemperatureSensor_Recall/DallasTemperatureSensor_Recall.ino
Hoffe, das führt weiter.
Zitat von: joe_re am 20 April 2016, 10:20:00
Hallo Hauswart,
das mit der eindeutigen Zuordnung der einzelnen Sensoren ist echt eine harte Nuss; ich habe damals die Lösung über das Array gewählt, weil ich keine Möglichkeit gesehen habe, auf andere Weise sicherzustellen, dass der von FHEM "gesehene" Wert auch zum "richtigen" Sensor paßt.
Nachdem ich jetzt gestern noch einige Tests gemacht habe und meine damalige Link-Liste durchgesehen habe, folgende Gedanken:
- Zuordnung innerhalb FHEM:
Hier scheint FHEM derzeit mit anderen Infos außer der Temperatur nichts anfangen zu können. Jedenfalls konnte ich auch bei mir die in Deinem Code nach jeder Messung übermittelte ID nirgendwo wiederfinden. Dann habe ich noch versucht, das im Rahmen der Presentation mögliche Kommentarfeld zu nutzen (nicht mal ein fester Text-String war in FHEM wiederzufinden, und einen Char* aus der Adresse machen, ist auch nicht so einfach...).
Aber vielleicht gibt es eine einfache Möglichkeit, das in das MYSENSORS-DEVICE-FHEM-Modul mit reinzubasteln (dann bliebe neben der Formatumwandlung "nur" noch die Frage, wie man das Kommentarfeld auswertbar macht; hier könnte man vielleicht aber auch den Reading-Namen auf den übermittelten Kommentar ändern, wenn ein solcher vorhanden ist; was ja nicht alle für Mysensors denkbaren Temperatursensoren erforderlich ist bzw. Sinn macht)
- Zuordnung auf der Arduino-Seite:
Hier kann man im Standard-Sketch m.E. nie sicher sein, ob sich die interne Nummerierung geändert hat, wenn "irgendwas" passiert (vom einfachen Reboot über den Ausfall einzelner Sensoren oder das Anklemmen neuer usw.).
Eine Lösung dazu wäre die mit dem starren Array, was aber erfordert, dass man vorher mühsam die Adressen ausliest und dann bei der Montage noch weiß, welche Adresse zu welchem der Kabel gehört. Umständlich eben.
Hier hat LeoDesigner einen interessanten Ansatz gewählt, nämlich dynamisch ein Array zu bilden und im EEPROM zu speichern. Das dürfte andere Nachteile haben, macht es aber dahingehend einfach, dass man "nur" jeweils die Sensoren einen nach dem anderen anschließt und den Arduino jeweils zwischendurch neu startet. Den entsprechenden Sketch (nicht getestet) gibt es unter https://github.com/leodesigner/mysensors-arduino/blob/master/DallasTemperatureSensor_Recall/DallasTemperatureSensor_Recall.ino (https://github.com/leodesigner/mysensors-arduino/blob/master/DallasTemperatureSensor_Recall/DallasTemperatureSensor_Recall.ino)
Hoffe, das führt weiter.
Kurz als Antwort, die ID wird in FHEM übertragen! Hatte ich oben vergessen zu erwähnen.
Bitte beim entsprechenden Device (autocreate) folgendes eingeben:
attr MYSENSOR_104 userreading mapReading_id 0 idLeider muss man derzeit die ID-Readings (noch) von Hand anlegen. Das Problem ist leider, dass die Beziehung Reading <=> Sensor nicht immer identisch ist, sondern variiert. Und da fehlt mir derzeit ein Ansatzpunkt wie ich weiter verfahren soll/muss.
Ok, aber was heißt das, dass die Beziehung Reading <=> Sensor variiert?
Bei einem Neustart des Arduino oder auch im laufenden Betrieb?
Was mir auch nicht so richtig klar ist, ist der Umstand, wieso die MYSENSORS-API das mit der ID überhaupt in der Form vorsieht. M.E. macht es eigentlich wenig Sinn, immer dieselben Informationen zu verfunken (und das nicht ein einziges Mal im Rahmen der Presentation zu erledigen und gut ist). Das wäre erst anders, wenn sich die interne Nummerierung der einzelnen Sensoren wirklich im laufenden Betrieb hin und wieder ändern würde?!?
Wenn das wirklich der Fall wäre, sollte man m.E. beide Ansätze kombinieren, also die interne Zuordnung (bereits) auf Arduino-Ebene verstetigen und dann die erweiterten Infos innerhalb FHEM nur noch zur Prüfung bzw. Ersteinrichtung zu benutzen.
Was die Erfahrungen mit meinem Array-Code angeht: Ich habe auch bei Neustarts und längerem Betrieb (jedenfalls soweit ersichtlich) keine Probleme, dass ich den "falschen" Meßwert in FHEM benutzt hätte; meine Graphen sehen jedenfalls soweit plausibel aus.
Zitat von: joe_re am 20 April 2016, 11:54:47
Ok, aber was heißt das, dass die Beziehung Reading <=> Sensor variiert?
Bei einem Neustart des Arduino oder auch im laufenden Betrieb?
Was mir auch nicht so richtig klar ist, ist der Umstand, wieso die MYSENSORS-API das mit der ID überhaupt in der Form vorsieht. M.E. macht es eigentlich wenig Sinn, immer dieselben Informationen zu verfunken (und das nicht ein einziges Mal im Rahmen der Presentation zu erledigen und gut ist). Das wäre erst anders, wenn sich die interne Nummerierung der einzelnen Sensoren wirklich im laufenden Betrieb hin und wieder ändern würde?!?
Wenn das wirklich der Fall wäre, sollte man m.E. beide Ansätze kombinieren, also die interne Zuordnung (bereits) auf Arduino-Ebene verstetigen und dann die erweiterten Infos innerhalb FHEM nur noch zur Prüfung bzw. Ersteinrichtung zu benutzen.
Was die Erfahrungen mit meinem Array-Code angeht: Ich habe auch bei Neustarts und längerem Betrieb (jedenfalls soweit ersichtlich) keine Probleme, dass ich den "falschen" Meßwert in FHEM benutzt hätte; meine Graphen sehen jedenfalls soweit plausibel aus.
Dies wären Punkte die man meiner Meinung nach genau testen müsste. Habe auch schon mit Tests begonnen. Im laufenden Betrieb verändern sich die IDs nicht (ausser wir fügen einen neuen Sensor hinzu, dann wird dieser Wert logischerweise auch übertragen)
1. Start:
ID1 = Sensor1
ID2 = Sensor2
Laufender Betrieb
ID1 = Sensor1
ID2 = Sensor2
Laufender Betrieb, Sensor hinzufügen
ID1 = Sensor1
ID2 = Sensor2
[neu] ID3 = Sensor3
Laufender Betrieb, Sensor 2 entfernen
ID1 = Sensor1
[ID2] wird nicht mehr aktualisiert
ID3 = Sensor3
Bei welchem Event, die IDs neu durchgezählt werden ist meine ich nach einem Reset. Dann werden nach Sensor-ID aufsteigend die IDs befüllt (siehe mein Screenshot).
Beispiel von oben Laufender Betrieb, Sensor hinzufügen
ID1 = Sensor1 - ID: 1001
ID2 = Sensor2 - ID: 1010
[neu] ID3 = Sensor3 - ID: 1002
1. Start nach Reset mit den 3 Sensoren:
ID1 = Sensor1 - ID: 1001
ID2 = Sensor3 - ID: 1002
ID3 = Sensor2 - ID: 1010
Zitat von: joe_re am 20 April 2016, 11:54:47
Was mir auch nicht so richtig klar ist, ist der Umstand, wieso die MYSENSORS-API das mit der ID überhaupt in der Form vorsieht. M.E. macht es eigentlich wenig Sinn, immer dieselben Informationen zu verfunken (und das nicht ein einziges Mal im Rahmen der Presentation zu erledigen und gut ist). Das wäre erst anders, wenn sich die interne Nummerierung der einzelnen Sensoren wirklich im laufenden Betrieb hin und wieder ändern würde?!?
Der Vorteil ist, ich kann im laufenden Betrieb neue Sensoren anschliessen :D
Zitat von: joe_re am 20 April 2016, 11:54:47
Wenn das wirklich der Fall wäre, sollte man m.E. beide Ansätze kombinieren, also die interne Zuordnung (bereits) auf Arduino-Ebene verstetigen und dann die erweiterten Infos innerhalb FHEM nur noch zur Prüfung bzw. Ersteinrichtung zu benutzen.
Was die Erfahrungen mit meinem Array-Code angeht: Ich habe auch bei Neustarts und längerem Betrieb (jedenfalls soweit ersichtlich) keine Probleme, dass ich den "falschen" Meßwert in FHEM benutzt hätte; meine Graphen sehen jedenfalls soweit plausibel aus.
Der Array ist sicherlich eine saubere Sache, aber man muss natürlich händisch den Sketch anpassen und bei jedem neuen Sensor wieder erweitern.
Jetzt bin ich erst mal beruhigt, dass das in etwa so statisch ist, wie ich vermutet hatte 8).
Zitat von: Hauswart am 20 April 2016, 13:22:39
Der Vorteil ist, ich kann im laufenden Betrieb neue Sensoren anschliessen :D
Dafür sehe ich allerdings jetzt nicht so die große Notwendigkeit; ich habe bisher eher versucht, alles stromlos zu machen, wenn ich irgendwas umkable ???.... Und dann wird doch eigentlich auch bei Presentation() die max. Anzahl an Sensoren vergeben/abgefragt und an den Controller übermittelt? Wird das wiederholt, wenn im laufenden Betrieb was geändert wird?
Zitat von: Hauswart am 20 April 2016, 13:22:39
Der Array ist sicherlich eine saubere Sache, aber man muss natürlich händisch den Sketch anpassen und bei jedem neuen Sensor wieder erweitern.
Genau hier setzt - jedenfalls wenn ich das richtig verstanden habe - der Sketch von LeoDesigner https://github.com/leodesigner/mysensors-arduino/blob/master/DallasTemperatureSensor_Recall/DallasTemperatureSensor_Recall.ino (https://github.com/leodesigner/mysensors-arduino/blob/master/DallasTemperatureSensor_Recall/DallasTemperatureSensor_Recall.ino) (nicht meiner) an: man muß die Adressen der einzelnen Dallase gar nicht vorher schon kennen, diese werden beim Start der Node automatisch und "on-the-fly" erfaßt und - so dort noch nicht vorhanden - (verhasht) ins EEPROM geschrieben. Der weitergehende Trick scheint zu sein, dass dann auch die Child-Sensor-ID nach der Position im EEPROM-Array vergeben wird, sich maW. also gerade nicht mehr ändert, wenn äußere Änderungen (z.B. mehr oder weniger Dallas-Sensoren) stattfinden. Nicht mehr besetzte Sensor-CHILD-ID's werden ausgelassen (nach 1 kommt 3, wenn es 2 nicht mehr gibt, ein neuer Sensor wäre dann 4), und zwar auch über Resets und Neustarts hinaus.
Das paßt jedenfalls so lange, bis man die Daten im EEPROM löscht oder das Array voll ist oder überläuft (häufige Wechsel oder so).
Wenn das tatsächlich funktioniert, sollte eigentlich recht pragmatisch gewährleistet sein, dass sich hinter der FHEM bekannt gemachten Child-ID jeweils immer dieselbe Hardware-ID verbirgt.
Vielleicht teste ich das heute Abend mal aus; das Thema hat mich auch so lange beschäftigt, dass es einfach super wäre, auch mal was beizutragen, was anderen hilft, Kopfzerbrechen und mangelnden WAF zu vermeiden... :-\
Zitat von: joe_re am 20 April 2016, 14:48:55
Genau hier setzt - jedenfalls wenn ich das richtig verstanden habe - der Sketch von LeoDesigner https://github.com/leodesigner/mysensors-arduino/blob/master/DallasTemperatureSensor_Recall/DallasTemperatureSensor_Recall.ino (https://github.com/leodesigner/mysensors-arduino/blob/master/DallasTemperatureSensor_Recall/DallasTemperatureSensor_Recall.ino) (nicht meiner) an: man muß die Adressen der einzelnen Dallase gar nicht vorher schon kennen, diese werden beim Start der Node automatisch und "on-the-fly" erfaßt und - so dort noch nicht vorhanden - (verhasht) ins EEPROM geschrieben. Der weitergehende Trick scheint zu sein, dass dann auch die Child-Sensor-ID nach der Position im EEPROM-Array vergeben wird, sich maW. also gerade nicht mehr ändert, wenn äußere Änderungen (z.B. mehr oder weniger Dallas-Sensoren) stattfinden. Nicht mehr besetzte Sensor-CHILD-ID's werden ausgelassen (nach 1 kommt 3, wenn es 2 nicht mehr gibt, ein neuer Sensor wäre dann 4), und zwar auch über Resets und Neustarts hinaus.
Das paßt jedenfalls so lange, bis man die Daten im EEPROM löscht oder das Array voll ist oder überläuft (häufige Wechsel oder so).
Wenn das tatsächlich funktioniert, sollte eigentlich recht pragmatisch gewährleistet sein, dass sich hinter der FHEM bekannt gemachten Child-ID jeweils immer dieselbe Hardware-ID verbirgt.
Vielleicht teste ich das heute Abend mal aus; das Thema hat mich auch so lange beschäftigt, dass es einfach super wäre, auch mal was beizutragen, was anderen hilft, Kopfzerbrechen und mangelnden WAF zu vermeiden... :-\
Jetzt habe ich es verstanden, oder vorhin überlesen :) Muss mir in einer ruhigen Minute den Sketch mal genauer anschauen und eventuell auf meinen Adaptieren. Das würde natürlich dazuführen, dass wir eine 1:1 Beziehung haben, welche wir ja möchten :)
Edit: Wann genau Presentation durchlaufen wird, weiss ich leider derzeit auch nicht genau... Habe dazu keine Dokumentation gefunden.
Beteilige mich gerne, v.a. am Testen!
Ist vermutlich besser, wie wenn ich versuche zu coden, es ist schließlich schon mühsam (und fehleranfälltig) genug, meine Gedanken zu vorhandenem Code verständlich auszudrücken...
Vielleicht noch eines in Ergänzung zu dem "Overflow-"Thema im EEPROM: Irgendwo hatte ich auch mal eine ähnlichen, aber viel älteren Sketch (nicht Mysensors) gesehen, der dann auch noch gecheckt hat, ob es noch freien Platz im EEPROM hat und dann nicht mehr aktiv genutzte Teile dieses Arrays mit neuen Sensor-IDs befüllen konnte. Das wäre dann die eierlegende Wollmilchsau, aber leider finde ich den Code nicht wieder :'(.
Dann würde ich noch anregen, die (einmalige) Übermittlung der ID in den Presentation()-Teil zu nehmen, ggf. im Rahmen einer eigenen Schleife ;)?
Das sieht eigentlich gar nicht schlecht aus! ::)
So, getestet und: überfordert... :( :( :(
Den Sketch von leodesigner in der Ausgangsfassung konnte ich nicht kompilieren, da meine Umgebung neuer ist (Arduino 1.6.7, Mysensors 2.0.0-beta).
Daher habe ich mich doch mal ans Überarbeiten und Zusammenfassen der Code-Varianten (und die EEPROM-bezogenen-Befehle geändert) gemacht, Ergebnis anbei (ACHTUNG: 1W-Anschluß: ich nutze die 5...).
Und die Feststellungen sind sehr gemischt:
Erst mal nur einen Sensor angeschlossen und diesen getauscht: Beide kommen jeweils auf die Child-ID 0 => Mist!!!
Dann habe ich zwei angeschlossen: Beide werden an FHEM übermittelt, die IDs sehe ich auf dem Seriellen Monitor => na ja, wenigstens was...
Dann einen der beiden wieder entfernt ("0"): der Andere bleibt auf der Child-ID 1 => Hurra!!!!
Also: Das Prinzip an sich scheint zu funktionieren, für weitere Tests (mehr Sensoren... habe ich heute abend keine Lust mehr). Fest steht jedenfalls, dass auch das Schreiben/Lesen ins EEPROM noch nicht so ist, wie es sein sollte; ich würde tippen, dass der Hash für den ersten Sensor ins digitale Nirvana wandert und nicht ins EEPROM. Vielleicht hat ein wirklicher Experte da mehr Durchblick?!?
Im Bette liegend kam mir dann die Vermutung, dass meine Erwartung schlicht zu hoch gewesen sein dürfte; das ganze funktioniert vermutlich, solange man die Zahl der Sensoren immer weiter erhöht, aber nicht, wenn man tauscht.
Die Initiierungs-/Speicherlogik muß nach meinem Geschmack um eine "Suche den ersten freien Platz im EEPROM bzw. wenn das nicht (mehr geht), den ersten nicht mehr benutzen Platz" erweitert werden. ;D
Wenn ich das richtig sehe, könnte man dafür die vorhandene Logik bei Setup() erweitern, indem man erst wirklich das ganze Array ts_sopt["i"] auf false setzt (nicht nur bis numSensors), dann aber nicht nur auf vorhandene Hardware prüft, sondern darauf, ob der Platz noch auf "00" steht (keine Ahnung, was dort steht, wenn frisch geflashed wurde?); die (jetzige) Schleife für vorhandene HW würde man dann nur nutzen, wenn alle Plätze im EEPROM belegt sind???
Ach so, das mit "attr MYSENSOR_106 userreading mapReading_id 0 id" ging gar nicht, die Fassung "attr MYSENSOR_106 userReadings mapReading_id 0 id" half auch nicht wirklich).
8)
Nachdenken hilft manchmal (hoffentlich):
Mittlerweile habe ich den Eindruck, dass der Sketch macht, was wir von ihm erwarten (und was leodesigner auch reingeschrieben hat) und meine Erwartungen schlicht an den Erfordernissen vorbei sind:
Entweder
- man nimmt einen Sensor ganz raus => dann macht es Sinn, die Nummerierung der übrigen nicht zu ändern (müßte so sein)
- man ersetzt einen Sensor => in der Regel soll dieser dann an die Stelle des nicht mehr vorhandenen treten (scheint so zu sein, allerdings habe ich das gestern noch als Bug wahrgenommen ;)...)
- man macht einen weitern, neuen dazu => hinten weiternummerieren (dürfte auch so sein)
Bin mal auf Eure Testergebnisse gespannt... ;D
OK, jetzt werde ich mutig 8)!
Unter http://hacks.ayars.org/2012_06_01_archive.html habe ich noch was ähnliches gefunden. Vorgehen dort: Erst alle Adressen erfassen im EEPROM, dann in der Reihenfolge auslesen, wie im EEPROM gespeichert (dort in zwei Sketchen, die gesamte Logik sollte aber mit überschaubarem Aufwand in den gestern gestrickten einzubauen sein).
Mein Gedanke jetzt: wäre es nicht besser, auf den Umweg mit der Hash-Wert-Bildung zu verzichten und das auch so zu machen??? Das lesen dauert u.U. etwas länger, der Platzbedarf im EEPROM ist höher, dafür entfällt die Umrechnerei und die Reihenfolge richtet sich nicht mehr nach den Verhältnissen auf dem Bus, sondern nach dem EEPROM. Damit sollte es eigentlich einfacher sein, die Infos zu "belegt" und "vorhanden" klarer zu sortieren (weil der Durchlaufindex i identisch bleiben kann).
Ich würde mir das so vorstellen, dass die nicht physisch vorhandenen, aber gespeicherten Adressen schlicht nicht ausgelesen/übersprungen werden (da ist ts_spot["i"] ja falsch).
Meinungen dazu?
Kann man irgendwie umgehen, dass FHEM automatisch eine 1 hinter die setreading Definition schreibt?
attr MYSENSOR_102 setReading_power11 1
attr MYSENSOR_102 setReading_power12 1
attr MYSENSOR_102 setReading_power13 1
attr MYSENSOR_102 setReading_power14 1
attr MYSENSOR_102 setReading_power15 1
Ich möchter gern beliebige Werte senden...
Ich kann die Einsen löschen, dann ist alles gut. Aber nach einem restart sind sie wieder da >:(
Bei >20 attr pro Device ist das ganz schön lästig :(
Nochmal zu dem Dallas-Index:
Anbei ein modifizierter Sketch mdB. um heavy testing! 8)
Einige Anmerkungen sind schon im Code enthalten. Das Prinzip ist, beim ersten Start die Hardwareaddressen in einer verkürzten, aber eindeutigen Form im EEPROM (also fest) zu speichern. Einmal dort, überleben sie nicht nur Neustarts, sondern sogar auch Modifikationen des Sketches und werden dann immer wieder als Child-IDs verwendet. Da ich es sowieso schon immer verwirrend fand, dass auch bei mehreren vorhandenen Sensoren binär gezählt wird (also temperature für den ersten Sensor, temperature1 für den zweiten, habe ich allerdings die Child-IDs um "1" erhöht, dann lässt es sich auch einfacher abfragen, ob wir den Sensor kennen oder nicht.
Bei jedem Neustart wird dann geprüft, ob die Adresse bekannt ist (also im EEPROM vorhanden). Wenn ja, benutzen wir wieder die gleiche Child-ID wie das letzte Mal (über ein Array). Kennen wir einen Sensor noch nicht, nutzen wir
- bei einem Tausch den Platz des getauschten im EEPROM zum Speichern, ansonsten
- (weiterer Sensor) den ersten nicht benutzten (maW. wird der zusätzliche dann der sein, der bei FHEM die höchste Nummer hat).
Das lädt zwar eventuell dazu ein, einen Sensor nach dem anderen einzubauen (dann weiß man, welchen man wo verbaut hat), ich würde aber eher empfehlen, erst mal die maximal angedachte Menge Sensoren anzuschließen (erklär ich weiter unten dann, warum). Dann kann man jeden einzeln dazubauen, und sieht dann in FHEM, unter welcher Nummer er sich meldet (alle anderen aktualisieren sich ja nicht bzw. die bekanntne kann man sich ja notieren).
Will man alles auf Anfang setzen, kann man einfach alle Dallase entfernen (das sollte man aber wohl tunlichst nach der Ersteinrichtung verhindern, indem man diese Option deaktiviert).
Meine Vermutung ist, dass die die Dallas-Library grundsätzlich den Bus so ordnet, dass die niedrigste HW-ID als erstes abgefragt wird usw. Daher ist der Hintergrund obiger Empfehlung, einmal mit allen Sensoren zu starten: Stimmt das, werden die ID's auch bei einem Löschen des EEPROM wieder in der gleichen Reihenfolge vergeben und gespeichert; das erspart das mühsame Suchen nach Auswirkungen in FHEM (wo ist welcher Meßwert verwendet...). Allerdings nur, wenn die Gesamtzahl unverändert ist ???.
Ansonsten spuckt der Sketch einiges an Debug-Info über die Konsole aus, was sich ebenso deaktivieren lassen sollte wie die Übermittlung der HardwareID auf die entsprechende Child-ID. Was mir (noch) nicht gelingen will, ist die Nutzung der Kommentar-Option von Mysensors, um die Hardware-ID gleich bei der Initialisierung mit zu übermitteln.
Wenn das aber tatsächlich alles funktioniert wie gedacht, sollte das eigentlich kein Problem mehr sein (wäre nur eine human-readable Debug-Hilfe, wenn doch mal alles durcheinandergehen sollte).
Viel Freude damit!
So, und nochmal eine Überarbeitung des Sketches zur Festnagelung der Dallas-IDs.
Änderungen:
- Bugfix betr. die Indexierung neuer Hardware, wenn man mehr als einen auf einmal dazufügt :(
- Rückkehr zur Nutzung der Mysensors-Speicherfunktion statt direktem Zugriff auf irgendwelche EEPROM-Adressen :-\
- Die erste Child-ID für die Dallase kann frei vergeben werden (sollte v.a. beim Zusammenbasteln mit Relays helfen, Probleme zu vermeiden) 8).
- Mehr Unterroutinen zur Verbesserung der Übersichtlichkeit ;)
Enjoy
Hallo,
ich habe mal den IR Sender/Empfänger in Betrieb genommen. (https://www.mysensors.org/build/ir)
Hat den vielleicht schon mal jemand ausprobiert?
Habe mir mit nem Nano ein Serial Interface gebaut und den Sensor auch mit nem Nano aufgebaut.
Scheint soweit zu funktionieren. Allerdings bietet der Sensor keine bisher gemappten readings.
Die empfangenen IR-Codes werden als Rohdaten in V_VAR1 gespeichert.
Wie komme ich denn in FHEM jetzt an die Daten und wie kann ich IR-Codes senden?
Der Sketch bietet anscheinend auch ein Decoding bekannter Codes an aber ich bekomme das nicht kompiliert wenn ich den Teil einkommentiere.
Edit:
Kleine Anmerkung. Toll wäre bei diesem Sensor natürlich eine Funktion zum IR-Code anlernen/speichern und zum späteren Versenden auf ein Command mappen.
Um hier nicht weiter Neuigkeiten zu dem Dallas-Index-Sketch zu posten, ist die aktuelle Fassung und ein weiterer Beispielsketch auf Basis eines manuell zu editierenden Arrays bei github unter https://github.com/rejoe2/MySensors-Dallas-Address-ChildID-Consistency abgelegt. Kommentare, Anregungen usw. sind willkommen 8).
Hallo r_knipp,
Glückwunsch zur erfolgreichen Inbetriebnahme des IR-Sensors!
Da ich gesehen habe, dass Du schon länger auch an dem Thema IR-Sender dran bist: Warum über MySensors und nicht die ESP-Lösung??? Das wäre nach meinem Gefühl eigentlich der schnellere Weg, oder?
Zu MySensors:
Die Node an sich scheint zu funktionieren, sie wird ja in FHEM angezeigt. Üblicherweise sollte dann noch ein neues Reading auftauchen (aber auch erst dann), wenn der Sensor etwas erkennt. Passiert denn in FHEM irgendwas, wenn Du mit einer Fernbedienung "spielst"? Was für eine hast Du denn (RC5/RC6 wäre vermutlich als Start ganz sinnvoll)?
Zitat von: joe_re am 02 Mai 2016, 11:07:02
Hallo r_knipp,
Glückwunsch zur erfolgreichen Inbetriebnahme des IR-Sensors!
Da ich gesehen habe, dass Du schon länger auch an dem Thema IR-Sender dran bist: Warum über MySensors und nicht die ESP-Lösung??? Das wäre nach meinem Gefühl eigentlich der schnellere Weg, oder?
Ja? Meinst du das ist der schnellere Weg? viegeners Lösung mit Arduino Mini könnte ich nochmal austesten. Hatte mich da irgendwie auf die ESP only Version versteift und die lief ja noch nicht als Sender/Empfänger.
Bei mysensors hatte ich die Hoffnung auf Aufbauen, anschließen und funktioniert. Aber da habe ich mir wohl mal wieder einen Sonderling rausgesucht.
Die Lösung mit mysensors würde ich ehrlich gesagt WiFi auch vorziehen. Aber ich denke, ich werde es heute Abend einfach mal mit dem ESP am Arduino ausprobieren.
Aber vielleicht hat ja trotzdem jemand mit ausreichend Know How Lust das Teil funktionsfähig zu machen.
Im Prinzip würde es ja reichen wenn man V_VAR1 auslesen könnte und das ganze dann unter einem Command speichern kann.
Zitat von: joe_re am 02 Mai 2016, 11:07:02
Zu MySensors:
Die Node an sich scheint zu funktionieren, sie wird ja in FHEM angezeigt. Üblicherweise sollte dann noch ein neues Reading auftauchen (aber auch erst dann), wenn der Sensor etwas erkennt. Passiert denn in FHEM irgendwas, wenn Du mit einer Fernbedienung "spielst"? Was für eine hast Du denn (RC5/RC6 wäre vermutlich als Start ganz sinnvoll)?
Ich habe bisher eine Fernbedienung von einem Panasonic DVD-Player getestet. Über die serielle Schnittstelle kommt halt der Code in Rohform.
In FHEM passiert gar nichts. Sicher dass da auch ein neues Reading auftauchen sollte? Bei den üblichen Sensoren wie Temp und Luftfeuchte bestimmt aber V_VAR1 ist nicht auf ein Reading gemappt. Denn wenn ich das richtig verstanden habe sind doch bestimmte Variablen, z.B. V_TEMP beim Temp-Sensor, auf entsprechende Readings gemappt, die dann bei Vorhandensein der Variablen angelegt werden.
Zitat von: r_knipp am 02 Mai 2016, 11:31:19
Ja? Meinst du das ist der schnellere Weg? viegeners Lösung mit Arduino Mini könnte ich nochmal austesten. Hatte mich da irgendwie auf die ESP only Version versteift und die lief ja noch nicht als Sender/Empfänger.
Bin auch nicht der Experte und habe mich in letzter Zeit auch nicht mehr mit IR befaßt... Es schient aber funktionierende Beispiele zu geben mit ESP-only. Z.B. https://alexbloggt.com/esp8266-smarthome-gateway/, wobei es dabei dann keine direkte Verbindung zu FHEM zu geben scheint. Als Vorteil der ESP-Lösung kam es mir vor, dass man die Befehle via http-request recht generisch an die Fernbedienung sendet (und damit wohl eher einfach einen FLOORPLAN erstellen könnte). Mir schwebte sowieso eigentlich eine "send-only"-Lösung vor, daher habe ich das mit dem Rückkanal bislang noch nicht so verfolgt.
Zitat von: r_knipp am 02 Mai 2016, 11:31:19
Im Prinzip würde es ja reichen wenn man V_VAR1 auslesen könnte und das ganze dann unter einem Command speichern kann.
Ich habe bisher eine Fernbedienung von einem Panasonic DVD-Player getestet. Über die serielle Schnittstelle kommt halt der Code in Rohform.
In FHEM passiert gar nichts. Sicher dass da auch ein neues Reading auftauchen sollte? Bei den üblichen Sensoren wie Temp und Luftfeuchte bestimmt aber V_VAR1 ist nicht auf ein Reading gemappt. Denn wenn ich das richtig verstanden habe sind doch bestimmte Variablen, z.B. V_TEMP beim Temp-Sensor, auf entsprechende Readings gemappt, die dann bei Vorhandensein der Variablen angelegt werden.
Dass V_VAR1 nicht gemappt wird, war mir offen gestanden nicht klar. Allerdings habe ich auch einen Pulszähler für's Gas, der auch mit V_VAR1 arbeitet. Und darunter kommt der aktuelle Zählerstand zurück (bzw. wird der letzte bekannte Zählerstand an die Node geschickt). Ob das bei den einzelnen Sensor-Node-Definitionen unterschiedlich ist, kann ich aber nicht sagen.
Wenn Du aber an der Konsole der Node beim IR-Empfang etwas als gesendet siehst, sollte sich das doch auch über die FHEM-Komandozeile an die Node schicken lassen, oder? Also copy aus der seriellen Konsole und dann via FHEM zurück wie ein abgelesener Zählerstand? Wenn das funktioniert, sollte man es auch z.B. über einen Floorplan-Link als command hinterlegen können?
Zitat von: joe_re am 02 Mai 2016, 13:01:18
Mir schwebte sowieso eigentlich eine "send-only"-Lösung vor, daher habe ich das mit dem Rückkanal bislang noch nicht so verfolgt.
Würde mir im Prinzip auch reichen. So oft muss man ja keine neuen Kommandos anlernen. Die kann man sicher auch aus der seriellen Konsole kopieren.
Wär nur halt bequemer mit nem Lernmodus ;)
Zitat von: joe_re am 02 Mai 2016, 13:01:18
Dass V_VAR1 nicht gemappt wird, war mir offen gestanden nicht klar. Allerdings habe ich auch einen Pulszähler für's Gas, der auch mit V_VAR1 arbeitet. Und darunter kommt der aktuelle Zählerstand zurück (bzw. wird der letzte bekannte Zählerstand an die Node geschickt). Ob das bei den einzelnen Sensor-Node-Definitionen unterschiedlich ist, kann ich aber nicht sagen.
Wenn Du aber an der Konsole der Node beim IR-Empfang etwas als gesendet siehst, sollte sich das doch auch über die FHEM-Komandozeile an die Node schicken lassen, oder? Also copy aus der seriellen Konsole und dann via FHEM zurück wie ein abgelesener Zählerstand? Wenn das funktioniert, sollte man es auch z.B. über einen Floorplan-Link als command hinterlegen können?
Hmm... Wenn das bei deinem Gaszähler funktioniert sollte es ja auch beim IR funktionieren. Da muss ich nochmal etwas rumprobieren.
Wie ich einen Code über FHEM senden soll kann ich mir allerdings noch nicht vorstellen. Das ist ganz schön viel. Werde heute Abend mal posten was am Terminal so ankommt.
Habe eben noch in die 10_MYSENSORS_DEVICE.pm gesehen (hoffe, das war die aktuelle Fassung). Dort steht
_______________________
S_IR => { receives => [V_IR_SEND], sends => [V_IR_RECEIVE] }, # Ir sender/receiver device
_______________________
Das würde das fehlende Mapping erklären; vielleicht reicht es, die Presentation-Bezeichnung im Sketch anzupassen?
Der Sketch arbeitet als S_LIGHT bzw. für ausgehende Nachrichten V_VAR1 und für ankommende V_LIGHT?
Mmh da sind einige Variablen zusammengewürfelt.
Probiere doch mal meinen Sketch (leicht modifiziert): https://github.com/Kolbi/Arduino/blob/patch-2/libraries/MySensors/examples/IrSensor/IrSensor.ino
Danach das alte Device aus FHEM löschen und neu pairen.
Interessante Sache, das und die Bezeichnungen/Variablen gehen wohl wirklich ordentlich durcheinander.
Wenn ich das mit meinen (Gas-) Wasserzähler vergleiche:
Ist es nicht so, dass FHEM unter "Sends" erwartet, was von Seiten des Sensors kommt?
Dann müßte es korrekterweise im Sketch heißen: MyMessage msg(CHILD_1, V_IR_RECEIVE); (nicht V_IR_SEND)
Will man von Seiten FHEM einen "echten" IR-Code (wie unter IR_RECEIVE empfangen) versenden, müßte man das der Variable IR_SEND so wie empfangen mit auf den Weg geben.
Hauswarts Sketch geht dort m.E. aber im Moment noch nicht weit genug, weil die umgewandelte S_LIGHT-Mimik immer noch "hart" mit einem ganz bestimmten "lauter" bzw. "leiser"-Signal verbunden ist und nur zwischen "1" und "irgendetwas anderes" unterscheidet. Nach meinem Empfinden müßte man dort eine (deutlich kompliziertere?) Logik hinterlegen bzw. evtl. auch "nur" den Message-Inhalt an irsend() übergeben? Müßte ich (oder besser jemand, der leichter die richtigen Kommandos dafür findet und zusammenbastelt) auch erst mal ausprobieren...
ABER: Sieht mir nach einem Ansatz aus! 8) Vielleicht wird das doch noch schneller als gedacht etwas mit meinem IR-Projekt!
Die IR Logik in Sketch ist natürlich individuell anzupassen. Die wird so wohl nicht gehen. Habe aber mir IR auch noch nie genau angeschaut.
So, ich bin etwas weiter gekommen. Mein geänderter Sketch im Anhang.
In FHEM passiert bei Tastendruck auf Fernbedienung nichts.
Das steht zum Sensor im Logfile:
2016.05.02 19:18:49 3: MYSENSORS: ignoring internal-msg from unknown radioId 100, childId 255 for I_REQUEST_SIGNING
2016.05.02 19:18:49 3: MYSENSORS: ignoring presentation-msg from unknown radioId 100, childId 255, sensorType 17
2016.05.02 19:18:49 3: MYSENSORS: ignoring internal-msg from unknown radioId 100, childId 255 for I_CONFIG
2016.05.02 19:18:51 3: MYSENSORS: ignoring internal-msg from unknown radioId 100, childId 255 for I_SKETCH_NAME
2016.05.02 19:18:51 3: MYSENSORS: ignoring internal-msg from unknown radioId 100, childId 255 for I_SKETCH_VERSION
2016.05.02 19:18:51 3: MYSENSORS: ignoring presentation-msg from unknown radioId 100, childId 3, sensorType 20
2016.05.02 19:19:27 3: MYSENSORS: ignoring internal-msg from unknown radioId 100, childId 255 for I_REQUEST_SIGNING
Dies bekommt man über den seriellen Monitor in Arduino:
sensor started, id=100, parent=0, distance=1
send: 100-100-0-0 s=255,c=3,t=11,pt=0,l=9,sg=0,st=ok:IR Sensor
send: 100-100-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=ok:1.0
send: 100-100-0-0 s=3,c=0,t=20,pt=0,l=0,sg=0,st=ok:
Decoded Unknown: Value:0 (0 bits)
Raw samples(100): Gap:3314
Head: m3450 s1750
0:m400 s450 1:m400 s1300 2:m450 s450 3:m400 s450
4:m400 s450 5:m400 s450 6:m400 s450 7:m450 s450
8:m400 s450 9:m400 s450 10:m400 s450 11:m450 s450
12:m400 s450 13:m400 s1300 14:m400 s450 15:m450 s450
16:m400 s450 17:m400 s450 18:m400 s450 19:m450 s450
20:m400 s1300 21:m400 s1300 22:m450 s450 23:m400 s1300
24:m400 s450 25:m450 s400 26:m450 s450 27:m400 s450
28:m400 s450 29:m400 s450 30:m450 s450 31:m400 s450
32:m400 s1300 33:m450 s450 34:m400 s450 35:m400 s450
36:m400 s450 37:m400 s450 38:m450 s450 39:m400 s450
40:m400 s1300 41:m450 s400 42:m450 s450 43:m400 s450
44:m400 s1300 45:m450 s1300 46:m400 s450 47:m400 s1300
48:m450
Extent=55550
Mark min:400 max:450
Space min:400 max:1300
Wenn ich den Code des Moduls richtig verstanden habe empfängt es V_IR_SEND und sendet V_IR_RECEIVE.
Edit:
Habs mal mit meiner Wordclock-Ferbedienung (Scheckkarten-FB) ausprobiert. Da erkennt er sogar manchmal NEC Code.
Cool, dass das vorangeht. Allerdings:
Zitat von: r_knipp am 02 Mai 2016, 19:37:11
Wenn ich den Code des Moduls richtig verstanden habe empfängt es V_IR_SEND und sendet V_IR_RECEIVE.
Tippe eher auf den genau umgekehrten Fall:
Zitat von: joe_re am 02 Mai 2016, 14:39:07
Wenn ich das mit meinen (Gas-) Wasserzähler vergleiche:
Ist es nicht so, dass FHEM unter "Sends" erwartet, was von Seiten des Sensors kommt?
Dann müßte es korrekterweise im Sketch heißen: MyMessage msg(CHILD_1, V_IR_RECEIVE); (nicht V_IR_SEND)
Will man von Seiten FHEM einen "echten" IR-Code (wie unter IR_RECEIVE empfangen) versenden, müßte man das der Variable IR_SEND so wie empfangen mit auf den Weg geben.
Willst Du das nicht einfach mal ausprobieren?
Zitat von: joe_re am 02 Mai 2016, 21:44:45
Tippe eher auf den genau umgekehrten Fall:
Im Modulcode steht:
S_IR => { receives => [V_IR_SEND], sends => [V_IR_RECEIVE] }, # Ir sender/receiver device
Aber ich probiere mal nach deinem Vorschlag aus.
Vielleicht hattest du Recht. Ich habe jetzt auf jeden Fall ein Reading, das sich bei Tastendruck ändert.
Allerdings steht immer nur fffff... oder 0000... drin.
Ich dachte MyMessage msg (); sendet den empfangenen Code an FHEM und das Modul empfängt daher V_IR_SEND.
Scheint wohl andersrum zu sein.
Dann bezieht sich die Angabe im Code wohl auf den Sensor und nicht auf das Modul?
Hallo,
Sorry vielleicht für die Dumme Frage, beschäftige mich erst seit kurzer Zeit mit MySensors.
Ich habe jetzt ein ESP 8255 als WLAN Gateway was auch funktioniert und connected
An einem Nano mit einem NF24L01+ habe ich einen MQ-135 laufen am Serial Port sehe ich das er auch schön Daten liefert.
nach diesem Muster https://www.mysensors.org/build/gas
Im FHEM habe ich
define MySensorsGateway MYSENSORS 192.168.x.x:5003
attr MySensorsGateway autocreate 1
attr MySensorsGateway first-sensorid 1
attr MySensorsGateway requestAck 1
attr MySensorsGateway room MySensors
attr MySensorsGateway stateFormat connection
set MySensorsGateway inclusion-mode on
Ich dachte das FHEM jetzt den MQ-135 selbst findet und anlegt, oder irre ich mich, den es passiert nichts. Oder muss ich das per Hand zu Fuß machen?
Du musst am Gateway den Inclusion Mode einschalten. Dann findet er den Sensor automatisch.
set gateway inclusion-mode on
in deinem Fall.
Danke für die schnelle Antwort.
Wie findet eigentlich MySensors seine "Clients"?
Beim MQ-2/MQ-135 ist sowas im script nicht hinterlegt.
Wenn ich das richtig verstanden habe, sendet der Sensor beim Start eine presentation message (bestimmt auch zwischendurch im Betrieb?), die unter anderem auch seinen Typ enthält. Damit weiß das Gateway dass ein neuer Sensor da ist und was für einer es ist.
Schau mal hier: https://www.mysensors.org/download/serial_api_14
Zitat von: Edi77 am 03 Mai 2016, 01:08:21
Wie findet eigentlich MySensors seine "Clients"?
Beim MQ-2/MQ-135 ist sowas im script nicht hinterlegt.
Der MQ-2 ist als "AIR_QUALITY" definiert und auch so in der MYSENSORS_DEVICE.pm als typ. Beispiel genannt. Wenn das bei Dir in der "Presentation" auch so ist (wie im Beispielsketch von der MySensors-Seite), müßte es eigentlich funktionieren.
Die Presentation wird (jedenfalls nach meinen bisherigen Beobachtungen) nur beim Start der Node durchlaufen, allerdings immer wieder wiederholt, bis ein Controller (FHEM) eine Node-ID zurückgibt (die wird dann allerdings gespeichert und bleibt auch bei einem erneuten Flashen erhalten). Das kann man ganz gut auf der seriellen Konsole der Node nachvollziehen. (Wenn Du die Node-ID ggf. doppelt vergeben/in 2 Arduinos gespeichert hast, solltest Du für die Node manuell (im Sketch) eine (neue) ID vergeben.
Wenn also FHEM Deine Node nicht "sieht", obwohl "inclusion mode" an ist, dürfte es ein Problem mit dem Funk sein (v.a. Reichweite oder ein fake-NRF). Beobachte mal die serielle Konsole der Sensor-Node.
Steht der Funkverkehr grundsätzlich, sollte das Device auch automatisch angelegt werden. Damit ist aber noch nicht gesagt, dass auch die übermittelten Werte ohne weiteres verwendbar sind; auch hier müssen die Angaben des Sensors und des FHEM-Moduls zueinander passen (da kämpfen wir grade beim IR-Modul rum, sonst hatte ich bislang damit (fast) keine Probleme...).
Zitat von: r_knipp am 02 Mai 2016, 21:52:00
Im Modulcode steht:
S_IR => { receives => [V_IR_SEND], sends => [V_IR_RECEIVE] }, # Ir sender/receiver device
Aber ich probiere mal nach deinem Vorschlag aus.
Sorry hatte den Sketch nochmal korrigiert und das IR_RECEIVE vergessen zu korrigieren: https://github.com/Kolbi/Arduino/blob/patch-2/libraries/MySensors/examples/IrSensor/IrSensor.ino
So sollte es von der Senden / Empfangen Logik stimmen.
Zitat von: Hauswart am 03 Mai 2016, 09:22:04
Sorry hatte den Sketch nochmal korrigiert und das IR_RECEIVE vergessen zu korrigieren: https://github.com/Kolbi/Arduino/blob/patch-2/libraries/MySensors/examples/IrSensor/IrSensor.ino
So sollte es von der Senden / Empfangen Logik stimmen.
Leider nicht. Wie Joe_re schon angemerkt hatte, muss es andersrum sein.
Ich habs auch ausprobiert und es kommt etwas in FHEM an.
Die Angabe im Modulcode hinter dem Device Typ bezieht sich auf den Sensor.
Zum Beispiel diese Sensoren
S_TEMP => { receives => [], sends => [V_TEMP] }, # Temperature sensor
S_HUM => { receives => [], sends => [V_HUM] }, # Humidity sensor
S_BARO => { receives => [], sends => [V_PRESSURE,V_FORECAST] }, # Barometer sensor (Pressure)
S_WIND => { receives => [], sends => [V_WIND,V_GUST] }, # Wind sensor
S_RAIN => { receives => [], sends => [V_RAIN,V_RAINRATE] }, # Rain sensor
S_UV => { receives => [], sends => [V_UV] }, # UV Sensor
S_WEIGHT => { receives => [], sends => [V_WEIGHT,V_IMPEDANCE] }, # Weight sensor for scales etc.
senden alle Messwerte an FHEM und empfangen nichts.
Der IR-Sensor empfängt V_IR_SEND und sendet V_IR_RECEIVE.
Er empfängt also vom Gateway einen IR-Code, den er weitersenden (V_IR_SEND) soll, und empfängt (V_IR_RECEIVE) von einer Fernbedienung einen IR-Code, den er ans Gateway weiterleitet.
Es muss also heißen MyMessage msg(CHILD_1, V_IR_RECEIVE);
Zitat von: r_knipp am 02 Mai 2016, 22:31:32
...ein Reading, das sich bei Tastendruck ändert.
Allerdings steht immer nur fffff... oder 0000... drin.
Mangels Hardware (jedenfalls bisher):
Gibt es einen Zusammenhang zwischen dem, was Du in der Konsole siehst und den aktualisierten Readings? Ist das auch so bei den Tasten, die der Sensor dekodieren konnte (von Deiner Scheckkarten-FB) oder eher im Sinne eines "toggle"??
Grundsätzlich gibt es eine Begrenzung der jeweils übertragbaren Datenmenge; wenn also bei einem einzigen Tastendruck mehrere Linien Text erzeugt werden, ist das vermutlich nicht zu realisieren (Aus der API 1.5: The maximum payload size is 25 bytes!). :(
Wenn es so wäre, dass dekodierte Tastendrücke auch übermittelt werden, RAW aber nicht, müßtest Du das konkrete FB-Protokoll der Hardware, die Du nutzen willst im Sensor zur (De-)codierung hinterlegen ::)...
ABER: das wäre vermutlich bei jeder Übertragungstechnik so, wenn es klappt, wärst Du deutlich weiter als zu vermuten war (aber MySensors scheint immer für angenehme Überraschungen gut zu sein).
Zitat von: joe_re am 03 Mai 2016, 11:16:28
Grundsätzlich gibt es eine Begrenzung der jeweils übertragbaren Datenmenge; wenn also bei einem einzigen Tastendruck mehrere Linien Text erzeugt werden, ist das vermutlich nicht zu realisieren (Aus der API 1.5: The maximum payload size is 25 bytes!). :(
Also ich würde mal ganz stark davon ausgehen, dass das als Hex ankommt.
Wie das, was testweise gesendet werden soll (siehe Sensor-Sketch).
irsend.send(NEC, 0x1EE17887, 32); // Vol up yamaha ysp-900
Vorausgesetzt er kann es dekodieren.
Zitat von: joe_re am 03 Mai 2016, 11:16:28
Gibt es einen Zusammenhang zwischen dem, was Du in der Konsole siehst und den aktualisierten Readings? Ist das auch so bei den Tasten, die der Sensor dekodieren konnte (von Deiner Scheckkarten-FB) oder eher im Sinne eines "toggle"??
Ich werde heute Abend mal ein paar Fernbedienungen durchtesten.
Vielleicht auch mal testweise einen Sender aufbauen mit bekanntem und vom Sensor sicher dekodierbarem Protokoll?
Zitat von: r_knipp am 03 Mai 2016, 11:42:59
Also ich würde mal ganz stark davon ausgehen, dass das als Hex ankommt.
Wie das, was testweise gesendet werden soll (siehe Sensor-Sketch).
irsend.send(NEC, 0x1EE17887, 32); // Vol up yamaha ysp-900
Na ja, es dürfte nicht nur der HEX-Code sein; in der Regel muß auch die Art der Codierung mit übergeben werden (wie hier "NEC", das findet sich auch in anderen IR-Projekten, wo diese Info dann z.B. als Teil des http-Strings oä. mitgegeben wird).
Habe eben noch ein wenig gesucht, auch bei anderen Controllern gibt es diverse Probleme, wenn der FB-Code nicht bekannt ist, vgl. z.B. http://www.domoticz.com/forum/viewtopic.php?f=42&t=10678 und hier http://www.domoticz.com/forum/viewtopic.php?f=42&t=10678.
Werde wohl heute abend auch mal einen Receiver aufbauen und ausprobieren, was mit meinen FB's so klappt (oder auch nicht). Ans Senden würde ich mich allerdings erst mal noch nicht machen, ohne das näher verstanden zu haben. Zum einen könnte man immer noch hergehen und (bekannte) Codes hart mit Anweisungen verbinden (wie jetzt "1" und "alles andere"). Generischer wäre wohl, die komplette Sende-Anweisung aus dem Controller (FHEM) zu verschicken. Dazu muß aber das Dekodieren und Kodieren klappen (add new protocols).
@r_knipp: Möchtest Du Deinen aktuellen Code mal posten (bzw. github?)? (Würde aber eigentlich gerne bei der MySensors-2.0.0-beta-Version bleiben wollen, die ich aktuell schon ohne weitere Problemchen verwende und vom grundsätzlichen Sketchaufbau auch einleuchtender finde).
Zitat von: joe_re am 03 Mai 2016, 13:08:28
@r_knipp: Möchtest Du Deinen aktuellen Code mal posten (bzw. github?)? (Würde aber eigentlich gerne bei der MySensors-2.0.0-beta-Version bleiben wollen, die ich aktuell schon ohne weitere Problemchen verwende und vom grundsätzlichen Sketchaufbau auch einleuchtender finde).
Mein aktueller Code entspricht dem aus diesem Post: https://forum.fhem.de/index.php/topic,26807.msg446750.html#msg446750
Nur halt IR_SEND und IR_RECEIVE vertauscht, wie du vorgeschlagen hattest.
In der 2.0 Beta ist doch der gleiche IR Sketch drin wie in der 1.5
Sooo, ich habe relativ gute Nachrichten. Der Empfang klappt schon mal.
Hier die Power On Taste von der Fernbedienung meines Yamaha Receivers, den ich später auch damit steuern möchte.
send: 100-100-0-0 s=255,c=3,t=15,pt=2,l=2,sg=0,st=ok:0
send: 100-100-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,st=ok:1.5.4
send: 100-100-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=ok:0
read: 0-0-100 s=255,c=3,t=6,pt=0,l=1,sg=0:M
sensor started, id=100, parent=0, distance=1
send: 100-100-0-0 s=255,c=3,t=11,pt=0,l=9,sg=0,st=ok:IR Sensor
send: 100-100-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=ok:1.0
send: 100-100-0-0 s=3,c=0,t=20,pt=0,l=0,sg=0,st=ok:
Decoded NEC: Value:BE414DB2 (32 bits)
Raw samples(68): Gap:56762
Head: m8750 s4550
0:m550 s1700 1:m500 s600 2:m500 s1700 3:m550 s1700
4:m500 s1700 5:m550 s1700 6:m500 s1700 7:m550 s550
8:m550 s550 9:m550 s1700 10:m500 s600 11:m500 s600
12:m550 s550 13:m550 s550 14:m550 s550 15:m550 s1700
16:m500 s600 17:m500 s1700 18:m450 s650 19:m550 s600
20:m450 s1750 21:m550 s1700 22:m500 s600 23:m450 s1750
24:m450 s1800 25:m500 s600 26:m500 s1700 27:m550 s1700
28:m500 s600 29:m450 s650 30:m500 s1700 31:m550 s550
32:m550
Extent=67100
Mark min:450 max:550
Space min:550 max:1800
send: 100-100-0-0 s=3,c=1,t=33,pt=0,l=8,sg=0,st=ok:be414db2
Decoded NEC: Value:FFFFFFFF (0 bits)
Raw samples(4): Gap:39550
Head: m8750 s2350
0:m500
Extent=11600
Mark min:500 max:500
Space min:32767 max:0
send: 100-100-0-0 s=3,c=1,t=33,pt=0,l=8,sg=0,st=ok:ffffffff
Er kann den Code dekodieren und sendet ihn ans Gateway. Dieser empfängt den Code auch korrekt und zeigt ihn im Reading an.
Das müsst ihr mir leider einfach mal so glauben, denn wie man an der seriellen Ausgabe am Ende auch sieht empfängt er auch viel Mist.
Ich konnte leider nicht schnell genug einen Screenshot machen.
Der IR-Empfänger ist sehr sensibel und reagiert auch auf künstliches Licht. Jedenfalls hat die Halogenbeleuchtung in meiner Küche sehr viel falsche Signale erzeugt. Keine Ahnung wie man das unterbinden könnte. Vielleicht nicht erkannte Codes einfach nicht senden?
Im Reading steht dann übrigens in meinem geposteten Fall "be414db2".
Ich fahre morgen Nachmittag übers lange Wochenende weg, daher werde ich leider erst nächste Woche wieder dazu kommen mich intensiv damit zu beschäftigen.
Hallo
Ich habe mir mal die Concole angeschaut.
Wenn ich das ESP Gateway startet kommt öfters "Radio init fail"
welches meint er damit WLAN oder mysensors ???
Die Verbindung FHEM NodeMCU sollte gehen, ping geht auch, setze ich im FHEM ihn auf Connect oder disconnect tut sich was in der console.
Aber wie kann ich überprüfen ob die Sensoren gehen??
Habe mir noch einen nano mit einem DS18B20 gebaut, tut sich aber auch nichts.
ESP8266 MySensors Gateway
Connecting to xx
......Connected!
IP: 192.168.x.x
GateWay setup done!
0;0;3;0;9;radio init fail
Soft WDT reset
ctx: cont
sp: 3fff0090 end: 3fff02c0 offset: 01b0
>>>stack>>>
3fff0240: 00000000 00000000 3ffeefc8 4020389d
3fff0250: 3ffe8794 3ffef0d8 00000000 402014df
3fff0260: 40202298 00000001 00000000 40201eca
3fff0270: 3b01a8c0 00ffffff 3ffef1d4 3ffef290
3fff0280: 3ffe864c 3ffef0d8 3ffef1d4 40202707
3fff0290: 3ffe8790 3b01a8c0 feefeffe feefeffe
3fff02a0: 3fffdad0 00000000 3ffef288 40205ef0
3fff02b0: feefeffe feefeffe 3ffef2a0 40100718
<<<stack<<<
ets Jan 8 2013,rst cause:2, boot mode:(3,7)
load 0x4010f000, len 1264, room 16
tail 0
chksum 0x0f
csum 0x0f
~ld
ESP8266 MySensors Gateway
Connecting to xx
......Connected!
IP: 192.168.x.x
GateWay setup done!
0;0;3;0;9;gateway started, id=0, parent=0, distance=0
MySensors init done!
Server ready!
Client 0 connected
0;0;3;0;14;Gateway startup complete.
Client 0: 0;0;3;0;2;
0;0;3;0;2;1.5.4
Ich habe auch 2 verschiedene Typen vom NRF24L01+ müssten aber doch beide gehen?
(http://pic.admin4all.com/DSC05250.JPG)
Sorry das ich euch belästigt habe, scheint jetzt zu gehen, falsch verkabelter NRF24L01 :(
Der Sensor wurde vom FHEM gefunden, mal schauen ob es morgen Werte liefert, bin jetzt Hunde müde ...........
Edit 4.5. 10:30 Uhr
Der Air Qulity Sensor ist jetzt im FHEM aber es kommen keine Werte.
define MYSENSOR_1 MYSENSORS_DEVICE 1
attr MYSENSOR_1 IODev MySensorsGateway
attr MYSENSOR_1 mapReading_level 0 level
attr MYSENSOR_1 mapReading_unitprefix 0 unitprefix
attr MYSENSOR_1 mode node
attr MYSENSOR_1 room MySensors
attr MYSENSOR_1 verbose 5
attr MYSENSOR_1 version 1.5.4
Habe mal verbose auf 5 gestellt.
LOG
2016.05.04 10:30:24 3: Opening MySensorsGateway device 192.168.x.x:5003
2016.05.04 10:30:25 3: MySensorsGateway device opened
2016.05.04 10:30:25 5: MYSENSORS send: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=002(I_VERSION ) ack=0 ''
2016.05.04 10:30:25 5: SW: 303b303b333b303b323b0a
2016.05.04 10:30:25 5: MYSENSORS/RAW: /0;0;3;0;14;Gateway startup complete.
0;0;3;0;2;1.5.4
2016.05.04 10:30:25 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=014(I_GATEWAY_READY ) ack=0 'Gateway startup complete.'
2016.05.04 10:30:25 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=002(I_VERSION ) ack=0 '1.5.4'
2016.05.04 10:30:27 3: Logo125 S7_connect: connect to PLC with maxPDUlength=240
2016.05.04 10:30:29 5: MYSENSORS send: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=005(I_INCLUSION_MODE) ack=0 '1'
2016.05.04 10:30:29 5: SW: 303b303b333b303b353b310a
2016.05.04 10:30:29 5: MYSENSORS/RAW: /0;0;3;0;5;1
2016.05.04 10:30:29 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=005(I_INCLUSION_MODE) ack=0
2016.05.04 10:31:29 5: MYSENSORS/RAW: /0;0;3;0;5;0
2016.05.04 10:31:29 5: MYSENSORS Read: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=005(I_INCLUSION_MODE) ack=0 '0'
2016.05.04 10:31:29 5: MYSENSORS send: Rx: fr=000 ci=000 c=-01('' ) st=005('' ) ack=0 '1'
2016.05.04 10:31:29 5: SW: 303b303b2d313b303b353b310a
fr, ci und c sollten dann die Werte sein.
Wie bekomme ich die am besten in eine Log file ?
Vielleicht kann mir noch jemand sagen wie man am besten die fake NRF24L01+ von den echten unterscheiden kann?
Oder wo ihr die NRF24L01+ bezieht die gut laufen?
Zitat von: r_knipp am 03 Mai 2016, 23:02:26
Der IR-Empfänger ist sehr sensibel und reagiert auch auf künstliches Licht. Jedenfalls hat die Halogenbeleuchtung in meiner Küche sehr viel falsche Signale erzeugt. Keine Ahnung wie man das unterbinden könnte. Vielleicht nicht erkannte Codes einfach nicht senden?
void loop()
{
gw.process();
if (irrecv.GetResults(&decoder)) {
irrecv.resume();
decoder.decode();
decoder.DumpResults();
char buffer[10];
sprintf(buffer, "%08lx", decoder.value);
// Send ir result to gw
gw.send(msg.set(buffer));
}
}
Die Funktion decode() gibt anscheinend true oder false zurück.
Aus IRLib.cpp:
bool IRdecode::decode(void) {
if (IRdecodeNEC::decode()) return true;
if (IRdecodeSony::decode()) return true;
if (IRdecodeRC5::decode()) return true;
if (IRdecodeRC6::decode()) return true;
if (IRdecodePanasonic_Old::decode()) return true;
if (IRdecodeNECx::decode()) return true;
if (IRdecodeJVC::decode()) return true;
//if (IRdecodeADDITIONAL::decode()) return true;//add additional protocols here
//Deliberately did not add hash code decoding. If you get decode_type==UNKNOWN and
// you want to know a hash code you can call IRhash::decode() yourself.
// BTW This is another reason we separated IRrecv from IRdecode.
return false;
}
Das müsste man doch einfach abfragen können und nur bei true gw.send(msg.set(buffer)) ausführen.
Zitat von: r_knipp am 04 Mai 2016, 10:45:07
Das müsste man doch einfach abfragen können und nur bei true gw.send(msg.set(buffer)) ausführen.
Das wäre ein Lösungsansatz; evtl. könnte es auch helfen, einen Widerstand einzubauen (bzw. die Empfängerschaltung etwas aufzubohren). Was hast Du denn für einen Empfänger? Ein ganzes Modul wie auf der MySensors-Seite oder (wie ich) einen einzelnen Empfänger?
Für meinen (VS1838B) sähe das so aus wie im Anhang: 100 Ohm an VCC, 20 kOhm Pullup (OUT/VCC). Irgendwo fand ich auch den Hinweis, zwischen 100 Ohm und 330 Ohm zwischen OUT und Arduino-Pin zu hängen.
Nur mal so eine Idee
Es gibt von MySensors auch den Door/window/Button.
So wie ich das sehen gibt es das FHT80b / FHT80TF-2 nicht mehr.
Wäre es eine Lösung den MySensors Door/window/Button auszuwerten und wenn das Fenster/Tür offen/geschlossen über die FHEM CUL einen FHT80TF-2 für einen FHT80B zu emulieren? sprich das der FHEM dann ein FHT80TF-2 Signal sendet? ::)
Zitat von: Edi77 am 04 Mai 2016, 11:25:15
Nur mal so eine Idee
Es gibt von MySensors auch den Door/window/Button.
So wie ich das sehen gibt es das FHT80b / FHT80TF-2 nicht mehr.
Wäre es eine Lösung den MySensors Door/window/Button auszuwerten und wenn das Fenster/Tür offen/geschlossen über die FHEM CUL einen FHT80TF-2 für einen FHT80B zu emulieren? sprich das der FHEM dann ein FHT80TF-2 Signal sendet? ::)
Warum denn etwas emulieren? Weiß auch gar nicht wie das gehen sollte. Eines der beiden Geräte hat doch bestimmt ein Reading für Fenster offen/geschlossen.
Das Signal würde er doch sonst vom Fensterkontakt bekommen. Das sollte man doch dann in FHEM setzen können.
Zitat von: Edi77 am 04 Mai 2016, 11:25:15
Nur mal so eine Idee
Es gibt von MySensors auch den Door/window/Button.
So wie ich das sehen gibt es das FHT80b / FHT80TF-2 nicht mehr.
Wäre es eine Lösung den MySensors Door/window/Button auszuwerten und wenn das Fenster/Tür offen/geschlossen über die FHEM CUL einen FHT80TF-2 für einen FHT80B zu emulieren? sprich das der FHEM dann ein FHT80TF-2 Signal sendet? ::)
Sollte eigentlich kein Problem sein: http://www.fhemwiki.de/wiki/CUL_FHTTK und ein NOTIFY/IF/DOIF sollten diesen Job erledigen können.
Zitat von: joe_re am 04 Mai 2016, 11:12:25
Was hast Du denn für einen Empfänger? Ein ganzes Modul wie auf der MySensors-Seite oder (wie ich) einen einzelnen Empfänger?
Ich habe die bei MySensors empfohlene Sender/Empfänger-Kombi. War am einfachsten anzuschließen.
Ich habe aber auch noch TSOP1738 rumliegen. Könnte ich auch mal ausprobieren. Aber leider erst nächste Woche.
Zitat von: joe_re am 04 Mai 2016, 11:44:03
Sollte eigentlich kein Problem sein: http://www.fhemwiki.de/wiki/CUL_FHTTK und ein NOTIFY/IF/DOIF sollten diesen Job erledigen können.
Kannte ich noch gar nicht. Dann sollte das doch gehen.
Aber was ist denn mit diesem: http://www.elv.de/homematic-hm-sec-sc-funk-tuer-fensterkontakt-1.html
Ok... etwas teurer als ein MS-Sensor...
Wäre auch eine alternative zum FHT80TF-2 müsste dann aber noch ein Gate für Homematic haben.
Müsste sowieso mal dann schauen wie lange der Mysensors mit Batterie klar kommt, ist ja auch nicht unerheblich.
Oh, das ist ja gar kein Homematic was du da haben willst? Sah so nach Homematic aus das Teil.
Wenn du noch kein Homematic nutzt würde ich an deiner Stelle für sowas dann wohl bei MySensors bleiben.
Zitat von: Edi77 am 04 Mai 2016, 12:47:47
Wäre auch eine alternative zum FHT80TF-2 müsste dann aber noch ein Gate für Homematic haben.
Müsste sowieso mal dann schauen wie lange der Mysensors mit Batterie klar kommt, ist ja auch nicht unerheblich.
Zitat von: r_knipp am 04 Mai 2016, 13:17:06
Oh, das ist ja gar kein Homematic was du da haben willst? Sah so nach Homematic aus das Teil.
Wenn du noch kein Homematic nutzt würde ich an deiner Stelle für sowas dann wohl bei MySensors bleiben.
r_knipp hat da teilweise recht: das Versenden der Befehle an den FHT ist Slow-RF (433MHz), sollte also auch über einen Eigenbau-CUL/FHEMDuino (oder ähnliches, evtl. sogar eine Mysensors-Node) gehen, wenn Du die Investition in einen "echten" CUL scheuen solltest. HM-Unterstützung ist jedenfalls m.E. nicht zwingend erforderlich.
Batteriebetriebener MySensor: Keine Erfahrungen, kommt aber wohl auf den Arduino (5V/3.3V) an und darauf, wie oft Du messen willst (bzw. wie lange jeweils den Arduino schlafen legen könntest) bzw. wie schnell die Reaktion erfolgen soll. Wenn es nur um die Heizung geht, sollten alle 5 Min (oder mehr) reichen, der HK ist ja eh' träge. Vielleicht ginge auch ein "power-on" bei Fensteröffnung, aber da bin ich nicht der Experte...
Hallo,
Hatte gestern noch mit ein paar Nachbauten von Arduino pro mini 3,3V gebastelt.
Ich hab da kein sketch drauf bekommen, hatte einen CH340 und einen FTDI Adapter mit 3,3V.
An einem Adruino pro mini 5V laufen die Adapter.
Ich habe mir jetzt mal noch einen anderen Nachbau pro mini 3,3V bestellt.
Ich denke auch 3 - 5 min. Abfrage sollte ausreichen.
Die Tür/Fenster Kontakte soll der Zustand auch noch an eine Alarmzentrale weiter gemeldet werden, da reicht mir aber diese Zeit auch aus.
Ich denke so könnte ich dort wo ich nicht verkabeln kann, ein Tür/Fenster Kontakt für ca. 10Euro realisieren.
Hier: http://forum.mysensors.org/topic/3540/ir-sender-for-stereo-receiver/5
können wir uns die Senderoutine für den IR Sender/Empfänger abgucken :)
Ich frage mich nur noch wie das aussehen muss, was man aus FHEM an den Sensor schickt. ???
Zitat von: r_knipp am 04 Mai 2016, 14:32:43
Hier: http://forum.mysensors.org/topic/3540/ir-sender-for-stereo-receiver/5
können wir uns die Senderoutine für den IR Sender/Empfänger abgucken :)
Ich frage mich nur noch wie das aussehen muss, was man aus FHEM an den Sensor schickt. ???
Entweder so (dann tut die Node-Senderseite weiter so, als wäre sie ein "Light", wir können also nur on oder off senden), oder wir nutzen die IR-Funktionalität (was mir besser gefallen würde).
Das könnte wie folgt aussehen:
- Wir kennen dann irgendwann ja die Codes und die zugehörigen Protokolle (im Idealfall alles NEC, habe auch einen Yamaha!).
- Zumindest IR_RECEIVE ist ein char*, also sollte es IR_SEND auch sein? Dann müßte man eigentlich den ganzen Sendebefehl von FHEM aus absetzen können, also z.B. "set MYSENSORS_100 Reading_irsend3 NEC, 0x1EE17887, 32", müßte das nur als char empfangen ("char* incomingIrMessage = message.getChar();") und dann könnte evtl. schon ein schlichtes "irsend.send(incomingIrMessage);" ausreichen. (Die Befehle sind erstmal frei erfunden...)
Das wäre m.E. optimal, weil dann der Sensor selbst überhaupt nichts mehr wissen muß ;D => das wäre dann auch einfach zu erweitern.
- Geht das nicht, müßte zumindest der HEX-Wert versendbar sein. Dann besteht die Möglichkeit, irsend schon unter Angabe des zu verwendenden Protokolls aufzurufen (also "irsend.sendNEC(1EE17887)"). Unterschiedliche FB-Typen/Protokolle müßte man dann evtl. über unterschiedliche Child-ID's unterscheiden ;).
- Geht das alles auch nicht, könnte man die von FHEM kommenden Sendekommandos über ein Array (ggf. im EEPROM gespeichert) in "vollwertige" Sendekommandos umwandeln. (Ein Beispiel dazu habe ich mir irgendwo notiert, aber Puh :-\...)
Zitat von: joe_re am 04 Mai 2016, 15:10:04
Entweder so (dann tut die Node-Senderseite weiter so, als wäre sie ein "Light", wir können also nur on oder off senden), oder wir nutzen die IR-Funktionalität (was mir besser gefallen würde).
Warum nur on/off? Ich meinte die Senderoutine:
void incomingMessage(const MyMessage &message) {
//Determine the child device
uint8_t child = message.sensor;
//Get the relay status for the child device
int incomingRelayStatus = message.getInt();
//Emit the appropriate IR code to the child device
iremitter.send( childIR[child].brand, incomingRelayStatus == 1 ? childIR[child].onIRcode : childIR[child].offIRcode, childIR[child].bits);
//If sending to HD tuner, add "enter" code after preset code
if (child == 2){
//Don't send the enter command immediately after the number. Must wait a bit
delay(500);
iremitter.send (SONY,0xCBC8, 20);
}
oder habe ich das falsch verstanden? Damit sollte sich doch ein beliebiger IR-Code senden lassen mit Hersteller, Hex-Code, Länge in Bits.
Warum er den Sensor als S_LIGHT registriert verstehe ich auch nicht.
Zitat von: r_knipp am 04 Mai 2016, 15:38:25
Warum nur on/off? Ich meinte die Senderoutine:
Wenn ich den Code richtig deute, ist das - soweit es die von Seiten des Controllers kommenden Infos angeht - "nur" eine aufgebohrte Version eines Relays (oder Light, was praktisch dasselbe ist), das im Prinzip nur "on" und "off" (=relayStatus) kennt. Hier allerdings in der Fassung, dass mehrere Relays präsentiert werden, welche dann von "on" bzw. "off" in ein ganz konkret hinterlegtes IR-Sende-Signal übersetzt werden. Also: je präsentiertem Relay ein "on"-IR-Kommando und eines "off". (EDIT: Im Falle des "on"-Signals an den HD-... ist es eine Sequenz, die abläuft, aber immer noch hart vercoded)
Was mir vorschwebt, nutzt den Typ "IR_SEND" und geht in etwa so:
void receive(const MyMessage &message) {
const char *irData;
// We will try to send a complete send command from controller side, e.g. "NEC, 0x1EE17887, 32"
if (message.type==V_IR_SEND) {
irData = message.getString();
Serial.println(F("Received IR send command..."));
Serial.println(irData);
irsend.send(irData);
}
// Start receiving ir again...
irrecv.enableIRIn();
}
}
;) abgekupfert von https://github.com/mysensors/Arduino/blob/development/libraries/MySensors/examples/HeatpumpIRController/HeatpumpIRController.ino
Kompletter, noch nicht getesteter Sketch unter https://github.com/rejoe2/Mysensors-IR (2.0.0-beta, der Schnipsel oben sollte aber auch auf der 1.5 gehen!)
Hallo,
Ich hätte da noch mal eine Frage.
Das WLAN Gateway läuft ja jetzt, und ein Temperatursensor mit einem DS18B20 auch
Log auf dem COM Port
req id
send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,st=ok:
read: 0-0-255 s=255,c=3,t=4,pt=0,l=3,sg=0:10
send: 10-10-0-0 s=255,c=3,t=15,pt=2,l=2,sg=0,st=fail:0
send: 10-10-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,st=ok:1.5.4
send: 10-10-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=ok:0
read: 0-0-10 s=255,c=3,t=6,pt=0,l=2,sg=0:M
id=10
send: 10-10-0-0 s=0,c=1,t=0,pt=7,l=5,sg=0,st=ok:23.5
send: 10-10-0-0 s=0,c=1,t=0,pt=7,l=5,sg=0,st=ok:23.3
send: 10-10-0-0 s=0,c=1,t=0,pt=7,l=5,sg=0,st=ok:23.1
send: 10-10-0-0 s=0,c=1,t=0,pt=7,l=5,sg=0,st=ok:23.0
send: 10-10-0-0 s=0,c=1,t=0,pt=7,l=5,sg=0,st=ok:22.9
send: 10-10-0-0 s=0,c=1,t=0,pt=7,l=5,sg=0,st=ok:22.8
send: 10-10-0-0 s=0,c=1,t=0,pt=7,l=5,sg=0,st=ok:22.7
send: 10-10-0-0 s=0,c=1,t=0,pt=7,l=5,sg=0,st=ok:22.6
send: 10-10-0-0 s=0,c=1,t=0,pt=7,l=5,sg=0,st=ok:22.5
send: 10-10-0-0 s=0,c=1,t=0,pt=7,l=5,sg=0,st=ok:22.9
send: 10-10-0-0 s=0,c=1,t=0,pt=7,l=5,sg=0,st=ok:23.0
send: 10-10-0-0 s=0,c=1,t=0,pt=7,l=5,sg=0,st=ok:22.6
send: 10-10-0-0 s=0,c=1,t=0,pt=7,l=5,sg=0,st=ok:22.5
Und so sieht das im FHEM aus :)
2016.05.05 00:14:20 5: MYSENSORS/RAW: /10;0;1;0;0;22.5
2016.05.05 00:14:20 5: MYSENSORS Read: Rx: fr=010 ci=000 c=001(C_SET ) st=000(V_TEMP ) ack=0 '22.5'
2016.05.05 00:21:16 5: MYSENSORS/RAW: /10;0;1;0;0;22.9
2016.05.05 00:21:16 5: MYSENSORS Read: Rx: fr=010 ci=000 c=001(C_SET ) st=000(V_TEMP ) ack=0 '22.9'
2016.05.05 00:21:54 5: MYSENSORS/RAW: /10;0;1;0;0;23.0
2016.05.05 00:21:54 5: MYSENSORS Read: Rx: fr=010 ci=000 c=001(C_SET ) st=000(V_TEMP ) ack=0 '23.0'
2016.05.05 00:22:31 5: MYSENSORS/RAW: /10;0;1;0;0;22.6
2016.05.05 00:22:31 5: MYSENSORS Read: Rx: fr=010 ci=000 c=001(C_SET ) st=000(V_TEMP ) ack=0 '22.6'
2016.05.05 00:23:47 5: MYSENSORS/RAW: /10;0;1;0;0;22.5
2016.05.05 00:23:47 5: MYSENSORS Read: Rx: fr=010 ci=000 c=001(C_SET ) st=000(V_TEMP ) ack=0 '22.5'
Wie kann man darauf eine gute Log Datei machen für einen Plot?
Gibt es irgendwelche Parameter?
Zitat von: Edi77 am 05 Mai 2016, 00:23:06
Wie kann man darauf eine gute Log Datei machen für einen Plot?
Gibt es irgendwelche Parameter?
Daraus gar nicht. Du musst doch in deinem MySensors Device ein Reading für die Temperatur haben. Das nutzt du für ein Log.
define log_temp filelog log_temp-%y-%m-%d.log ms_device:.tempSo in etwa sollte das gehen. Dann wird jeden Tag ein neues Logfile angelegt. Schau dir mal die Commandref zu FILELOG an.
Zitat von: r_knipp am 04 Mai 2016, 11:47:42
Ich habe die bei MySensors empfohlene Sender/Empfänger-Kombi. War am einfachsten anzuschließen.
Ich habe aber auch noch TSOP1738 rumliegen. Könnte ich auch mal ausprobieren. Aber leider erst nächste Woche.
Zwischenstand, nachdem ich jetzt auch einen funktionierenden Empfänger habe: Die 000000 und fffffff sind m.E. repeat bzw. "0" codes des NEC-Protokolls, hatte den Effekt ebenfalls und auch selten ein Decode für die Yamaha-Receiver.
Habe eben auf Basis der von https://github.com/ElectricRCAircraftGuy stark überarbeiteten IRLib (und 2.0.0-beta) einen aktuelisierten Sketch nach https://github.com/rejoe2/Mysensors-IR/tree/master/IrSensor hochgeladen, der neben dem reinen Code auch die Protokoll-Infos schickt (allerdings "1" für NEC, "3" für RC5 etc..
In Senderichtung kann man zwar auch einen String senden (also dieselbe Info), allerdings wandelt die Node das nicht automatisch in sinnvolle Befehlscodes... Da ist also noch einiges zu tun, aber es sollte nicht unlösbar sein (mache jetzt aber erst mal Pause).
Zitat
Die 000000 und fffffff sind m.E. repeat bzw. "0" codes des NEC-Protokolls, hatte den Effekt ebenfalls und auch selten ein Decode für die Yamaha-Receiver.
Also bei wurden die 0 und f erzeugt wenn ich den Empfänger vor den Halogenlampen geschwenkt habe. Da brauchte ich nicht mal eine Taste auf der FB drücken.
Hallo,
Wie ein normales reading geht ist mir schon klar nur nicht bei mysensors
Meine config für diesen Sensor sieht so aus
define MYSENSOR_10 MYSENSORS_DEVICE 10
attr MYSENSOR_10 IODev MySensorsGateway
attr MYSENSOR_10 mapReading_temperature 0 temperature
attr MYSENSOR_10 mode node
attr MYSENSOR_10 room MySensors
attr MYSENSOR_10 verbose 5
attr MYSENSOR_10 version 1.5.4
# define FileLog_MYSENSOR_10 FileLog ./log/MYSENSOR_10-%Y.log MYSENSOR_10
# attr FileLog_MYSENSOR_10 logtype text
# attr FileLog_MYSENSOR_10 room MySensors
Mir ist noch nicht ganz klar wo er mapReading temperature 0 temerature hin schreibt, den das ist ja der Wert den ich brauche ..............
Edit
Hat sich erledigt, funktioniert
Zitat von: joe_re am 05 Mai 2016, 11:48:05
Habe eben auf Basis der von https://github.com/ElectricRCAircraftGuy stark überarbeiteten IRLib (und 2.0.0-beta) einen aktuelisierten Sketch nach https://github.com/rejoe2/Mysensors-IR/tree/master/IrSensor hochgeladen, der neben dem reinen Code auch die Protokoll-Infos schickt (allerdings "1" für NEC, "3" für RC5 etc..
OK, habe auch mal auf 2.0 beta upgedated, damit ich da auf dem gleichen Stand bin.
Mal ne Frage zu deinem Sketch.
Ich dachte in Arduino wird erst die setup() ausgeführt und dann die loop(). Wie wird denn die presentation() ausgeführt. Oder wird pauschal alles einmal ausgeführt, was vor der loop() kommt?
Hallo,
spiele immer noch mit dem MQ-135 herum.
Der MQ-135 soll ja CO2 SO2 NH3 NH4 CH3 CO messen können.
Hier gibt es ein schöne Sketch für einige Gas Sensoren, läuft aber wohl nicht auf einem Nano.
https://github.com/empierre/arduino/blob/master/AirQuality-Multiple_Gas_Sensor1_4.ino
Das hier läuft auch, liefert aber nur CO2
https://github.com/GeorgK/MQ135
genau so wie dieses hier
https://github.com/empierre/arduino/blob/master/AirQuality-MQ135.ino
Für mich wäre aber noch NH3 interessant und die anderen Werte.
Hat das schon mal jemand hin bekommen?
Zitat von: Edi77 am 05 Mai 2016, 21:58:47
Hallo,
spiele immer noch mit dem MQ-135 herum.
Der MQ-135 soll ja CO2 SO2 NH3 NH4 CH3 CO messen können.
Hier gibt es ein schöne Sketch für einige Gas Sensoren, läuft aber wohl nicht auf einem Nano.
https://github.com/empierre/arduino/blob/master/AirQuality-Multiple_Gas_Sensor1_4.ino
Das hier läuft auch, liefert aber nur CO2
https://github.com/GeorgK/MQ135
genau so wie dieses hier
https://github.com/empierre/arduino/blob/master/AirQuality-MQ135.ino
Für mich wäre aber noch NH3 interessant und die anderen Werte.
Hat das schon mal jemand hin bekommen?
Hi, ich spiele auch schon länger damit und habe auch das Datenblatt gelesen, ich denke nicht dass du mit dem MQ-135 einzelne Gase erkennen kannst, das ist ein Air-quality sensor der auf alle beschriebenen Gase mit Änderung des Messwiderstandes reagiert, du kannst aber aufgrund des Messwiderstandes nicht ein bestimmtes Gas erkennen. D.h. Ich habe einfach einen Schwellwert für gute Luft definiert (halbe Stunde im Garten gemessen) und das ist meine Referenz.
Mehr gibt dieser Sensor nicht her.
Hallo,
Ich habe ja auch den CO20 im Einsatz, und hatte den auch draußen eingesetzt, was natürlich auch zu Fehlmessungen führte weil nicht Temperaturkompensiert.
Ich will den MQ-135 auch draußen einsetzen, weil einige Bauern gern Gülle zu nah am Wohngebiet einsetzen, da wäre NH3 schon interessant wenn man das einzeln auswerten könnte, den beim AirQuality-Multiple_Gas_Sensor1_4.ino scheint das ja zu gehen. AirQuality-Multiple_Gas_Sensor1_4.ino so wie ich das sehe muss das auf einem Arduino Mega laufen, muss ich mal testen, den hier werden die einzelnen Gase ja angezeigt.
Für das kalibieren sollte man den Sensor bei ca. 20C draußen auf CO2 400ppm einstellen.
Ich glaube nicht dass das geht, solltest du das aber hinbekommen wäre es interessant.
Sent from my iPad using Tapatalk
Hallo,
Habe mir die Skechts und die Datenblätter mal angeschaut, und es ist wohl richtig das man nur einen Gesamtwert geliefert bekommt.
Daher denke ich bleibt der Multible Gas Sensor interessant. Wenn man z.B. einen reinen CO2 Sensor hat, kann man bei gleichbleibenden CO2 Werte aber abfallenden Werte bei einem anderen Sensor ausschließen das es CO2 ist usw.
So könnte Wertänderung beim einen Sensor mit einem anderen Sensor abgleichen und evtl. so das Gas heraus finden welches Gas gerade in der Luft ist.
Frage: hat schon mal jemand versucht, den "echten" IR_SEND-Modus in FHEM zu nutzen?
FHEM meckerte eben: "ir_send3 not defined: no mapping for reading ir_send3". Jemand eine Idee, wie das zu konfigurieren ist?
Und wenn es dann mit dem Versenden des kompletten Sendekommandos klappen sollte: Beim Kompilieren hatte ich die Rückmeldung, dass irsend.send() drei Argumente haben möchte, ich aber nur eines liefern würde, und das auch noch als String, was gar nicht ginge... Vor ich mir mit viel trial-und-error den Kopf zerbreche: Hat jemand einen Lösung parat, wie man einen String wie "3, 0x00001522, 13" wieder in die Einzelteile zerlegt, die "3" durch "RC5" ersetzt (ok: Array, aber am liebsten entsprechend dem jeweiligen Stand der Dinge in der IRLib ;))
und dann möglichst effektiv an irsend.send() übergibt????
Zitat von: r_knipp am 05 Mai 2016, 21:02:07
OK, habe auch mal auf 2.0 beta upgedated, damit ich da auf dem gleichen Stand bin.
Mal ne Frage zu deinem Sketch.
Ich dachte in Arduino wird erst die setup() ausgeführt und dann die loop(). Wie wird denn die presentation() ausgeführt. Oder wird pauschal alles einmal ausgeführt, was vor der loop() kommt?
presentation() ist Teil der geänderten Notation in der 2.0.0-Version von Mysensors. Vorneweg: Es funktioniert... Nach meinem Verständnis ist das als Teil der setup-routine innerhalb von MySensorCore.cpp definiert. Es scheinen also mehrere Ebenen zu sein, die im Rahmen des Kompilierens dann ineinander geschoben werden (so jedenfalls mein laienhaftes Verständnis).
Bist Du weitergekommen mit den 0000... und fff... (In meinem Sketch habe ich das schlicht als nicht zu versenden rausgefiltert).
Zitat von: joe_re am 08 Mai 2016, 11:50:16
Frage: hat schon mal jemand versucht, den "echten" IR_SEND-Modus in FHEM zu nutzen?
FHEM meckerte eben: "ir_send3 not defined: no mapping for reading ir_send3". Jemand eine Idee, wie das zu konfigurieren ist?
Und wenn es dann mit dem Versenden des kompletten Sendekommandos klappen sollte: Beim Kompilieren hatte ich die Rückmeldung, dass irsend.send() drei Argumente haben möchte, ich aber nur eines liefern würde, und das auch noch als String, was gar nicht ginge...
Ich denke du meinst void send(IRTYPES Type, unsigned long data, unsigned int data2); in der IRLib?
Ich würde den String zerlegen. Schau mal hier: http://www.cprogramming.com/tutorial/string.html unter Searching and Substrings.
Type würde ich dann über eine Art Mapping erzeugen. data2 müsste man per Typecasting in int ändern können.
Bei data wüsste ich jetzt nicht. Der IR-Code ist dockeigentlich HEX, aber die Funktion erwartet ein long.
Zitat von: joe_re am 08 Mai 2016, 11:50:16
Bist Du weitergekommen mit den 0000... und fff... (In meinem Sketch habe ich das schlicht als nicht zu versenden rausgefiltert).
Noch nicht. Bin noch unterwegs. Heute Abend bin ich wieder zu Hause. Dann werde ich weiter testen.
Würde ich aber auch so machen, oder halt das Ergebnis der decode() Funktion abfragen.
Werde aber auch noch mal den TSOP1738 ausprobieren. Vielleicht hat sich das mit einem anderen Empfänger ja auch erledigt.
Vielleicht auch mal ne anderer Lib ausprobieren?
Der IRMP (https://www.mikrocontroller.net/articles/IRMP) funktioniert wohl sehr zuverlässig und sollte auf dem Arduino doch auch laufen.
Zitat von: r_knipp am 08 Mai 2016, 13:40:02
Ich denke du meinst void send(IRTYPES Type, unsigned long data, unsigned int data2); in der IRLib?
Ist etwas mißverständlich; ich spreche von zwei Dingen:
Zum einen nämlich ging es um die Frage, ob jemand aus FHEM "irgendetwas" via der Variabel IR_SEND
an eine MySensors-Node (zurück) verschickt hat (das klappt bei mir nämlich weder mit einem String, noch mit einer "0" oder "1". Hast Du da eine Idee? (Wäre es evtl. eine Idee, die Node auch als "Custom" zu deklarieren, dann ginge es evtl. mit V_VAR1, oder hätte man da dasselbe Problem? Sollte man die Variable evtl. initialisieren, indem man den letzten Wert beim Controller abfragt???? Vielleicht geht es dann?)).
Zum anderen ging es dann um das Thema, wie den String zerlegen und das typecasting machen. Da werde ich mir die von Dir genannten Seiten mal zu Gemüte führen... War aber mit dem umgekehrten Weg (sprintf()) schon recht lange beschäftigt, um den vollständigen Code an FHEM zu versenden.
Aktueller Sketch liegt in meinem repo auf Github, anbei auch ein screenshot, dann ist evtl. klarer, was ich mit meiner Fehlermeldung zu IR_SEND meinte.
Was die IRLib angeht: ich verwende diese: https://github.com/ElectricRCAircraftGuy/IRLib. Die erkennt jedenfalls meine Yamahe(NEC) recht ordentlich, allerdings muß ich auch die Wiederholcodes noch filtern.
Ich habs schon mal hinbekommen, dass der IR Typ als Text nach FHEM übertragen wird.
String IRType_string = Pnames(My_Decoder.decode_type);
char IRType[IRType_string.length()+1];
IRType_string.toCharArray(IRType,IRType_string.length()+1);
sprintf(buffer, "%s, 0x%08lX, %i", IRType, My_Decoder.value, IrBits);
Edit:
Senden aus FHEM geht auch:
attr mapReading_ir_send3 3 ir_send
damit das Reading auch auf die Variable gemappt wird.
Ich habe es nur noch nicht hinbekommen einen String wie NEC,0xBE414DB2,32 zu senden.
FHEM interpretiert das als drei Werte.
Also man muss sämtliche Befehle die man senden möchte als Readinsgwerte in setReading_ir_send3 eintragen.
Oder könnten wir vielleicht andere Trennzeichen verwenden und sie dann im Sensorsketch ersetzen?
Edit2:
Wenn ich das Reading manuell setze
set MYSENSOR_100 ir_send3 NEC,0xBE414DB2,32
wird es auch gleich wieder empfangen und dekodiert :)
Received IR send command...
NEC,0xBE414DB2,32
decoding
NEC, BE418D72, 32
send: 100-100-0-0 s=3,c=1,t=33,pt=0,l=19,sg=0,st=ok:NEC, 0xBE418D72, 32
NEC, 0xBE418D72, 32
Der Receiver schaltet aber nicht ein. Habe den Sensor direkt vor das Gerät gehalten. An der Reichweite kanns also nicht liegen.
Da läuft wohl noch beim Senden des IR etwas nicht so richtig. Da weiß ich jetzt aber erstmal nicht weiter.
Edit3:
Oh, ich sehe gerade der gesendete und dekodierte code stimmen nicht überein. :(
Ich sehe gerade, der Sendet noch gar kein IR. Ist doch auskommentiert.
Warum empfängt er dann nach dem "Senden" etwas? Verstehe ich nicht.
Moin,
sorry für die etwas wirren Posts. War dann wohl doch schon etwas zu müde gestern Abend.
Das Senden von und nach FHEM funktioniert jedenfalls.
Das Senden eines IR-Codes sollte ich dann heute Abend hoffentlich auch hinbekommen.
Die benötigten String-Funktionen, um den empfangenen String in die entsprechenden Argumente zu zerlegen, stehen jedenfalls in der Arduino-Referenz.
Vielleicht kann noch jemand sagen, wie ich einen Wert wie NEC,0xBE414DB2,32 als Attributwert speichern kann, ohne dass die Kommas als Trennzeichen gewertet werden.
Vielleicht hat ja auch noch jemand eine Lösung, wie man am besten die zu steuernden Geräte anlegen kann.
Also z.B. einen Receiver als Dummy mit entsprechenden Funktionen (On, Off, lauter, leise, ...).
Kann man das ohne großes DOIF Gefrickel hinbekommen?
@Joe_re
Ich habe übrigens die MySensors Lib 2.0.0 beta und die IRLib von ElectricRCAircraftGuy mit deinem aktuellen Sensorsketch als Grundlage genommen.
Zitat von: r_knipp am 08 Mai 2016, 23:54:22
Ich habs schon mal hinbekommen, dass der IR Typ als Text nach FHEM übertragen wird.
String IRType_string = Pnames(My_Decoder.decode_type);
char IRType[IRType_string.length()+1];
IRType_string.toCharArray(IRType,IRType_string.length()+1);
sprintf(buffer, "%s, 0x%08lX, %i", IRType, My_Decoder.value, IrBits);
Edit:
Senden aus FHEM geht auch:
attr mapReading_ir_send3 3 ir_send
damit das Reading auch auf die Variable gemappt wird.
Ich habe es nur noch nicht hinbekommen einen String wie NEC,0xBE414DB2,32 zu senden.
Vielleicht kann noch jemand sagen, wie ich einen Wert wie NEC,0xBE414DB2,32 als Attributwert speichern kann, ohne dass die Kommas als Trennzeichen gewertet werden.
Auf das mapReading wäre ich wohl nie gekommen, herzlichen Dank!!!! Und auch das mit dem Senden des "NEC" ist evtl. auch ein deutlicher Fortschritt (braucht aber mehr Bandbreite zum Senden und ist nicht genau die erste Ziffer (für den "Rückweg")).
Könnte das mit dem String senden klappen, wenn man ihn in """" setzt? Also "NEC,0xBE414DB2,32"?
Zitat von: r_knipp am 09 Mai 2016, 08:09:40
Vielleicht hat ja auch noch jemand eine Lösung, wie man am besten die zu steuernden Geräte anlegen kann.
Also z.B. einen Receiver als Dummy mit entsprechenden Funktionen (On, Off, lauter, leise, ...).
Kann man das ohne großes DOIF Gefrickel hinbekommen?
Habe mich zwar noch nicht so recht mit der grafischen Aufarbeitung unserer neuen Möglichkeiten beschäftigt, aber evtl. läßt sich das mit remotecontrol (http://www.fhemwiki.de/wiki/Remotecontrol) recht einfach realisieren. Also die definierte remotecontrol mit dem MySensors-Device über "# Syntax:
set <name> makenotify <executingDevice>"koppeln (<executingDevice> = MYSENSORSDEVICE_XXX_IR_SEND oder so) und dann "einfach" direkt die jeweiligen FHEM-Sendekommandos hinterlegen?
"# Syntax:
attr <name> rowXX <command>:<icon>"
Könnte also so gehen: "attr <name> row01 NEC,0xBE414DB2,32:PLAY" 8)
Zitat von: r_knipp am 09 Mai 2016, 08:09:40
@Joe_re
Ich habe übrigens die MySensors Lib 2.0.0 beta und die IRLib von ElectricRCAircraftGuy mit deinem aktuellen Sensorsketch als Grundlage genommen.
@r_knipp: Pflege gerne Deine Änderungen (v.A., wenn das mit dem Aufsplitten klappt!!!) mit ein bzw. laß' Dich als Miteditor zu, wenn Du magst. Andererseits: Die von Dir genannte IRMP-Library könnte noch besser sein: Mehr Maintainer und die kann evtl. schon meinen Panasonic-Beamer, ohne dass ich irgendwelche LIRC-Files übersetzten müßte ;D? Würde das gerne mal ausprobieren, aber da sind die Aufrufe wieder anders, oder? (War gestern dann auch zu müde, um das zielführend anzugehen).
Zitat von: joe_re am 09 Mai 2016, 09:08:47
... und ist nicht genau die erste Ziffer (für den "Rückweg")).
Das verstehe ich nicht. Was meinst du?
Zitat von: joe_re am 09 Mai 2016, 09:08:47
Könnte das mit dem String senden klappen, wenn man ihn in """" setzt? Also "NEC,0xBE414DB2,32"?
Ich habe "" und () ausprobiert und gegoogelt. Aber nix gefunden.
Aber wahrscheinlich ist es auch gar nicht nötig die Befehle dort zu hinterlegen. Das wird man ja eher woanders machen wenn das so funktioniert, wie du es beschrieben hast.
Zitat von: joe_re am 09 Mai 2016, 09:08:47
@r_knipp: Pflege gerne Deine Änderungen (v.A., wenn das mit dem Aufsplitten klappt!!!) mit ein bzw. laß' Dich als Miteditor zu, wenn Du magst. Andererseits: Die von Dir genannte IRMP-Library könnte noch besser sein: Mehr Maintainer und die kann evtl. schon meinen Panasonic-Beamer, ohne dass ich irgendwelche LIRC-Files übersetzten müßte ;D? Würde das gerne mal ausprobieren, aber da sind die Aufrufe wieder anders, oder? (War gestern dann auch zu müde, um das zielführend anzugehen).
Also ich würde das gerne erstmal mit der jetzt verwendeten Lib komplett zum Laufen bekommen.
Klar, kannst mich gern als Miteditor eintragen. Habe bisher zwar nicht mit GitHub gearbeitet aber schon länger nen Account (rknipp).
Ja, bei der IRMP-Lib sind die Aufrufe sicher anders. Habe die auch noch nicht selber verwendet. Läuft aber in meiner Wordclock sehr zuverlässig.
Würde es aber, wie gesagt, gerne erstmal fertig bekommen. Das Umbauen des Sketches sollte dann ja aber kein großer Aufwand sein.
Kannst ja nen Fork von deiner Version machen und es parallel versuchen wenn du Lust hast.
Zitat von: joe_re am 09 Mai 2016, 09:08:47
Mehr Maintainer und die kann evtl. schon meinen Panasonic-Beamer, ohne dass ich irgendwelche LIRC-Files übersetzten müßte ;D?
Gerade mal durch den IRMP-Artikel geschaut. Panasonic Beamer ist seit November letzten Jahres drin. Leider kein BenQ :(
Muss ich doch weiter an der ESP8266 Serial Bridge basteln.
Hab gesehen, IRMP wurde auch für den ESP8266 portiert. Vielleicht auch ne Lösung. Fragt sich nur, wie an FHEM anbinden.
Aber das passt hier eigentlich nicht hin...
Es gibt aber auch einen Beispielsketch für Arduino. Sollte also auch funktionieren.
Zitat von: r_knipp am 09 Mai 2016, 09:57:50
Das verstehe ich nicht. Was meinst du?
Na ja, wir haben wohl grundsätzlich zwei Optionen, auf welche Art wir der Node von FHEM aus sagen, welches Protokoll verwendet werden soll:
1. entweder im Klartext ("NEC"). Das müssen wir dann mit einer Textanalyse aus dem FHEM-Sendekommando extrahieren wie vorgeschlagen
2. oder wir nehmen den numerischen Wert (derzeit kennt die IRLib 8 Protokolle oder so, das wäre also genau ausreichend für die erste Ziffer, die zurückgesendet wird) und übersetzten das dann erst wieder zum IR-Senden in Text (über eine Array-Zuordnung nach dem Motte: Protokolle[3]=NEC)
1 hat den Vorteil, dass wir Klartext reden und dann unabhängiger von der verwendeten IRLib sind, für andere dürfte es auch besser nachvollziehbar sein
2 braucht weniger Bandbreite, entsprach der alten Fassung des IR_RECEIVE und sah für meine Programmierkenntnisse damit einfacher realisierbar aus ;). Dann hatte ich noch den Eindruck, dass (zumindest bei meinen FB's) auch die irBits eigentlich immer in einer festen Korrelation zum Protokoll stehen. Wenn das so ist, könnte man auf der Node ein 2. Array definieren, das die passenden irBits auswirft und sich beim Senden aus FHEM dann darauf beschränken, statt "NEC,0xBE414DB2,32" dann "30xBE414DB2" zu senden; damit würde man übrigens wohl auch das Komma-Problem lösen ???
Zitat von: r_knipp am 09 Mai 2016, 09:57:50
Ich habe "" und () ausprobiert und gegoogelt. Aber nix gefunden.
Aber wahrscheinlich ist es auch gar nicht nötig die Befehle dort zu hinterlegen.
Sorry für den doofen Vorschlag mit dem "". Hoffe auch, wir brauchen die Kommandos nur einmal festzunageln und gut is...
Zitat von: r_knipp am 09 Mai 2016, 10:34:38
Gerade mal durch den IRMP-Artikel geschaut. Panasonic Beamer ist seit November letzten Jahres drin. Leider kein BenQ :(
Na ja, muß nix heißen; Yamaha=NEC... Vielleicht klappt es doch auch für BenQ mit dieser Lib, auch ohne dass es explizit erwähnt wäre.
Zitat von: r_knipp am 09 Mai 2016, 09:57:50
Also ich würde das gerne erstmal mit der jetzt verwendeten Lib komplett zum Laufen bekommen.
I'm absolutely with you! Kannte diese lib aber noch nicht, Panasonic-Unterstützung klang sehr verlockend und Du schienst zu wissen, wie es geht! Also: Übernächster Schritt oder so... ;D
Nach meinen Eindruck ist es wichtiger, erst mal den Transportweg für die Signale zu haben (und die "Knöpfe" in FHEM). Dann sollte es irgendwie auch möglich sein, die Protokolle zu erweitern (LIRC.conf-Übersetzungen...). Das dürfte langfristig zielführender sein, als gerade jetzt das Pferd zu wechseln ;)
Zitat von: r_knipp am 08 Mai 2016, 23:54:22
Senden aus FHEM geht auch:
attr mapReading_ir_send3 3 ir_send
damit das Reading auch auf die Variable gemappt wird.
Ich habe es nur noch nicht hinbekommen einen String wie NEC,0xBE414DB2,32 zu senden.
FHEM interpretiert das als drei Werte.
Also man muss sämtliche Befehle die man senden möchte als Readinsgwerte in setReading_ir_send3 eintragen.
Oder könnten wir vielleicht andere Trennzeichen verwenden und sie dann im Sensorsketch ersetzen?
Edit2:
Wenn ich das Reading manuell setze
set MYSENSOR_100 ir_send3 NEC,0xBE414DB2,32
wird es auch gleich wieder empfangen und dekodiert :)
Received IR send command...
NEC,0xBE414DB2,32
Habe vorhin auch das Reading gemapped, jetzt kann ich auch rückwärts (FHEM->Node) senden, es kommt auch was bei der Node an! Positiv: kann beliebige Strings senden, also auch "RC5,0x00001520,13" (ohne irgendwelche Klammern, Anführungszeichen oä.) ;D. Negativ: das klappt mal und klappt dann wieder nicht ???; kann noch keinen Zusammenhang erkennen :'(.
@r_knipp: Habe Dich als Coautor zugelassen, Sorry für das Durcheinander im Repo, der "eigentliche" Sketch ist dieser: https://github.com/rejoe2/Mysensors-IR/blob/master/IrSensor/IrSensor.ino.
In der IRMP-Library sind übrigens auch sehr viele Definitionen für Protokolle hinterlegt. Es scheint nicht das große Hexenwerk zu sein, aus einer (bekannten) LIRC.conf zumindest die Eckdaten abzulesen und damit dann auch in der jetzt verwendeten IRLib anzufügen. Der BenQ könnte auch ein verkappter NEC sein, scheint auch 32 irBits zu haben, vgl. http://lirc.sourceforge.net/remotes/benq/MP620 (man muß wohl die Angaben für pre_data und bits addieren). [/code]
Zitat von: r_knipp am 09 Mai 2016, 08:09:40
Vielleicht hat ja auch noch jemand eine Lösung, wie man am besten die zu steuernden Geräte anlegen kann.
Aktueller Zwischenstand:
Das Modul remotecontrol macht m.E. genau das. Nochmal im Zusammenhang die Schritte dafür:
- Mysensor-Node, die IR_SEND entgegenimmt (!= Beispiel-Sketch, der sich für den "Rückweg" wie ein "on/off"-Schalter verhält!)
- Das reading IR_SEND muß in FHEM manuell gemapped sein ("attr MYSENSOR_99 mapReading_ir_send3 3 ir_send")
- Mit "define Receiver remotecontrol" eine neue FB für FHEM definieren
- Layout für den Start: "set Receiver layout samsung"
- Device für's Versenden definieren: " set Receiver makenotify MYSENSOR_99 ir_send3"
- Tasten belegen: "attr Receiver row02 NEC 0x5EA111EE 32:1,2,3"
"1" auf "Receiver"-FB gedrückt => auf der seriellen Konsole ist zu sehen, dass die Node "NEC 0x5EA111EE 32" empfangen hat 8)
Das ist schon mal nicht übel, aber:
- Das Komma als Seperator verträgt sich nicht mit remotecontrol => Leerzeichen geht => muß im Sketch berücksichtigt werden (sollte aber kein Problem sein ;))
- OFFEN: Der empfangene Gesamtstring müßte im Sketch dann in seine Einzelteile zerlegt werden und diese dann jeweils wieder im "richtigen" Format an irsend() übergeben werden :( :( :( :'( Wenn also jemand eine auch für mich verständliche Lösung hat, BITTE, BITTE, BITTE!!!
Meine Versuche mit strtok() usw. sind ein ziemlicher Gang im Nebel, was irsend() braucht, ist: void send(IRTYPES Type, unsigned long data, unsigned int data2). Ein einziger String wie "NEC 0x5EA111EE 32" wird beim übersetzten zum einen nicht akzeptiert und jetzt sind auch tendenziell die Kommas raus...)
Alternative Wege erscheinen mir nicht mehr so naheliegend, da remotecontrol jeweils genau ein Sendedevice kennt (sonst könnte man mehrere ir_send[j] anlegen und darüber das zu verwendende Protokol definieren. Oder bin ich da auf dem Holzweg?
Zitat von: joe_re am 10 Mai 2016, 21:25:43
Aktueller Zwischenstand:
Das Modul remotecontrol macht m.E. genau das. Nochmal im Zusammenhang die Schritte dafür:
- Mysensor-Node, die IR_SEND entgegenimmt (!= Beispiel-Sketch, der sich für den "Rückweg" wie ein "on/off"-Schalter verhält!)
- Das reading IR_SEND muß in FHEM manuell gemapped sein ("attr MYSENSOR_99 mapReading_ir_send3 3 ir_send")
- Mit "define Receiver remotecontrol" eine neue FB für FHEM definieren
- Layout für den Start: "set Receiver layout samsung"
- Device für's Versenden definieren: " set Receiver makenotify MYSENSOR_99 ir_send3"
- Tasten belegen: "attr Receiver row02 NEC 0x5EA111EE 32:1,2,3"
"1" auf "Receiver"-FB gedrückt => auf der seriellen Konsole ist zu sehen, dass die Node "NEC 0x5EA111EE 32" empfangen hat 8)
Super dass das schonmal funktioniert.
Zitat von: joe_re am 10 Mai 2016, 21:25:43
Das ist schon mal nicht übel, aber:
- Das Komma als Seperator verträgt sich nicht mit remotecontrol => Leerzeichen geht => muß im Sketch berücksichtigt werden (sollte aber kein Problem sein ;))
Das Trennzeichen ist ja ziemlich egal.
Zitat von: joe_re am 10 Mai 2016, 21:25:43
- OFFEN: Der empfangene Gesamtstring müßte im Sketch dann in seine Einzelteile zerlegt werden und diese dann jeweils wieder im "richtigen" Format an irsend() übergeben werden :( :( :( :'( Wenn also jemand eine auch für mich verständliche Lösung hat, BITTE, BITTE, BITTE!!!
Meine Versuche mit strtok() usw. sind ein ziemlicher Gang im Nebel, was irsend() braucht, ist: void send(IRTYPES Type, unsigned long data, unsigned int data2). Ein einziger String wie "NEC 0x5EA111EE 32" wird beim übersetzten zum einen nicht akzeptiert und jetzt sind auch tendenziell die Kommas raus...)
Versuche ich mich auch schon seit gestern Abend dran. Doch komplizierter als ich dachte :(
IRTYPES ist übrigens ein unsigned char.
irData = message.getString();
irData ist ein pointer und getString() liefert halt einen pointer auf die message.
Die message ist ein char array, daher funktionieren die ganzen String Funktionen nicht.
Auf strtok() bin ich auch gekommen. Habe aber auch nichts vernünftiges hinbekommen.
Dieses pointer Gedöns ist auch echt tricky.
Zitat von: r_knipp am 10 Mai 2016, 21:37:28
Super dass das schonmal funktioniert.
Das Trennzeichen ist ja ziemlich egal.
Versuche ich mich auch schon seit gestern Abend dran. Doch komplizierter als ich dachte :(
Freu mich auch riesig; eigentlich habe ich so was seit mehr als 2 Jahren im Hinterkopf und mit LIRC beschäftige ich mich seit ca. 10 Jahren immer wieder, war aber noch nie so nah' an meinen Vorstellungen, unglaublich, dass es jetzt an so einer Erstsemesterübung hängt... ::) Andererseits: bin blutiger Anfänger mit C und Co, ist alles nur copy/paste mit trial/error (vor allem letzteres...)
Den Code habe ich etwas aufgeräumt und das mit dem Leerzeichen gleich umgesetzt, so dass es auf allen Ebenen einheitlich ist (Konsole/Versenden/Empfangen); wie üblich auf github.
Probier mal bitte das:
int i = 0;
char *arg[3] = {0,0,0};
char *irString = strdup(irData);
char *token = strtok(irString," ");
while(token != NULL){
strcpy(arg[i], token);
token = strtok(NULL, " ");
i++;
}
Serial.print("Protocol:"); Serial.print(*arg[0]);
Serial.print(" Code:"); Serial.print(*arg[1]);
Serial.print(" Bits:"); Serial.print(*arg[2]);
kommt hier her: http://stackoverflow.com/questions/8056146/breaking-down-string-and-storing-it-in-array
Es kompiliert. Ich kann aber gerade nicht test. Habe ein Verbindungsproblem mit MySensors. Muss ich erstmal wieder hinbekommen.
Das ist zum verrückt werden.
Der Sensor verbindet sich anscheinend.
Starting sensor (RNNNA-, 2.0.0-beta)
Radio init successful.
send: 100-100-0-0 s=255,c=3,t=15,pt=0,l=2,sg=0,st=fail:
send: 100-100-0-0 s=255,c=0,t=17,pt=0,l=10,sg=0,st=fail:2.0.0-beta
send: 100-100-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=fail:0
send: 100-100-0-0 s=255,c=3,t=11,pt=0,l=9,sg=0,st=fail:IR Sensor
send: 100-100-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=fail:1.0
send: 100-100-0-0 s=3,c=0,t=20,pt=0,l=0,sg=0,st=fail:
find parent
send: 100-100-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc:
Init complete, id=100, parent=0, distance=255
In FHEM wird er aber nicht angelegt.
Sensor und Gateway neu geflasht und Gateway auch neu angelegt.
Nach einem Neustart des Raspberry habe ich immer einen Sensor mit ID 0 als Repeater :(
Hast du eine Idee?
Edit:
Hat sich erledigt. Der Kondensator steckte nicht richtig am NRF. So was Blödes >:(
Mit dem oben geposteten Code startet der Controller bei Empfang neu. :o
Received IR se�Starting sensor (RNNNA-, 2.0.0-beta)
Radio init successful.
send: 100-100-0-0 s=255,c=3,t=15,pt=0,l=2,sg=0,st=ok:
send: 100-100-0-0 s=255,c=0,t=17,pt=0,l=10,sg=0,st=fail:2.0.0-beta
send: 100-100-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=ok:0
send: 100-100-0-0 s=255,c=3,t=11,pt=0,l=9,sg=0,st=ok:IR Sensor
send: 100-100-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=ok:1.0
send: 100-100-0-0 s=3,c=0,t=20,pt=0,l=0,sg=0,st=ok:
Init complete, id=100, parent=0, distance=1
Wie kann das denn????
Edit:
Es liegt an der while Schleife. Wenn ich die auskommentiere läufts.
So, bin jetzt so weit, dass der empfangene String richtig zerlegt wird.
Received IR send command...
NEC 0xBE414DB2 32
Protocol:NEC Code:0xBE414DB2 Bits:32
Jetzt noch die Typen richtig konvertieren,damit sie auch mit irsend() versendet werden könne.
Das aber morgen. Jetzt schlafen...
Zitat von: r_knipp am 11 Mai 2016, 01:45:59
So, bin jetzt so weit, dass der empfangene String richtig zerlegt wird.
Jetzt noch die Typen richtig konvertieren,damit sie auch mit irsend() versendet werden könne.
Das aber morgen. Jetzt schlafen...
Super, den Schlaf hast du dir redlich verdient!!!!!
Wenn du den aktuellen Code einpflegst bzw. mir zukommen läßt, aktualisiere ich den Sketch auf github...
Was das Konvertieren angeht: Unter https://github.com/markszabo/IRremoteESP8266/blob/master/examples/IRGCTCPServer/IRGCTCPServer.ino gibt es ein Beispiel, bei dem eine (als http://-String eingehende Message passend zerlegt wird (allerdings nur in zwei Teile, wenn ich das richtig verstehe)). Auch unter https://alexbloggt.com/esp8266-smarthome-gateway/ gibt es was dazu und dem Tutorial-Link unten (lesen von Serial).
Vielleicht hilft das weiter, mein derzeitiges Abstraktionsvermögen übersteigt es....
Dann:
- Laut http://tech.cyborg5.com/2013/04/22/irlib-tutorial-part-3a-sending-ir-codes/ kann man irsend() auch in der Form irsend(IRTYPES(int),...) aufrufen. Evtl. wäre es einfacher, statt "NEC" eine "1" (oder 3) zu senden; würde es nicht zumindest einen Teil der Konvertierung erleichtern, wenn wir die Teile praktisch nur numerisch hin und her schieben (und ggf. noch auf "0x" verzichten)?
- Was unsere FB's angeht:
Der Benq nutzt vermutlich das Samsung32-Protokoll, da gibt es ein Beispiel unter http://www.spech.de/blog/article/universalfernbedienung, wie das Protokoll in die (normale) IR-Lib einzubinden wäre.
Mein Panasonic-Beamer bräuchte wohl die Eckdefinitionen für neue Panasonic-TVs. Ansätze dafür gibt's hier: https://github.com/cyborg5/IRLib/pull/15
Aber eins nach dem anderen ;)
Bis frühestens heute Abend dann.
Zitat von: joe_re am 11 Mai 2016, 11:12:29
Wenn du den aktuellen Code einpflegst bzw. mir zukommen läßt, aktualisiere ich den Sketch auf github...
Ja, mache ich dann wenns läuft. Ist je eh "nur noch" die Konvertierung. Aber ich denke das wird auch noch. Hatte mir dazu gestern eigentlich schon alles rausgesucht.
Zitat von: joe_re am 11 Mai 2016, 11:12:29
..., bei dem eine (als http://-String eingehende Message passend zerlegt wird (allerdings nur in zwei Teile, wenn ich das richtig verstehe)).
Das coole an der der while Schleife mit der strtok() Funktion ist, dass die Anzahl der Teile egal ist. Das teilt so lange bis keine Trennzeichen mehr gefunden werden.
Man kann auch mehrere unterschiedliche Trennzeichen angeben.
Du kannst damit zum Beispiel auch NEC,0xBE414DB2:32 trennen mit strok(string,",:").
Ich hatte vor allem ziemlich Probleme mit den Pointern, da ich noch nie wirklich mit Pointern programmiert hatte. Bisher hauptsächlich Visual Basic und da brauchte ich die nicht.
Man lernt aber viel wenn man sich damit intensiv beschäftigt :)
Zitat von: joe_re am 11 Mai 2016, 11:12:29
- Laut http://tech.cyborg5.com/2013/04/22/irlib-tutorial-part-3a-sending-ir-codes/ kann man irsend() auch in der Form irsend(IRTYPES(int),...) aufrufen. Evtl. wäre es einfacher, statt "NEC" eine "1" (oder 3) zu senden; würde es nicht zumindest einen Teil der Konvertierung erleichtern, wenn wir die Teile praktisch nur numerisch hin und her schieben (und ggf. noch auf "0x" verzichten)?
Das ist ja eigentlich egal. Konvertieren muss ich es so oder so. Empfangen wird immer ein Pointer auf ein char Array. Ob ich das array nun nach int oder unsigned char konvertiere sollte eigentlich keinen Unterschied machen.
Hast du eigentlich mal die Reichweite deiner IR-Diode getestet? Hatte mal zum Test beim Empfang irgendeiner Nachricht das Power On Signal senden lassen, um zu testen, ob der Receiver sich damit überhaupt schalten lässt. Meine reicht vielleicht nen halben Meter. Da muss auf jeden Fall was viel kräftigeres her, vor allem da Beamer und Receiver sich natürlich auf entgegengesetzten Seiten des Raumes befinden.
Und hast du Erfahrung mit der Reichweite von MySensors? Aus meinem Abstellraum neben der Küche reicht es mit den normalen Modulen jedenfalls nicht annähernd bis ins Wohnzimmer. Habe das Gateway zum Testen erstmal am Aquarium-Raspi im Wohnzimmer hängen. Habe mir aber auch zwei NRF mit PA und Antenne bestellt. Die brauchen aber noch etwas aus China.
Zitat von: r_knipp am 11 Mai 2016, 11:59:06
Ob ich das array nun nach int oder unsigned char konvertiere sollte eigentlich keinen Unterschied machen.
Für's Konvertieren macht es evtl. keinen Unterschied, aber m.E. ist es besser, wenn es "universell" ist. Und der Panasonic- bzw. Samsung32-String braucht halt mehr Bandbreite als 2 Ziffern max. (zumal der Panasonic-Code dann auch nochmal eine Bitlänge von 56 hat (?)...
Zitat von: r_knipp am 11 Mai 2016, 11:59:06
Hast du eigentlich mal die Reichweite deiner IR-Diode getestet?
...ich habe nur Bauteile hier rumliegen, zum Senden bin ich vor lauter lauter noch gar nicht gekommen (ergo auch nicht zum Zusammenstöpseln). Plan ist, einen Widerstand, einen NPN in Verbindung mit mehreren Dioden in unterschiedlicher Ausrichtung in Reihe zu nutzen, Vorschläge dazu gibt's ja Zuhauf im Netz (muß ich aber auch erst wieder suchen).
Zitat von: r_knipp am 11 Mai 2016, 11:59:06
Und hast du Erfahrung mit der Reichweite von MySensors?
JAAA, Reichweitenprobleme bei Mysensors kenne ich gut ::). Ein PA-Modell am Gateway ist in jedem Fall eine gute Idee, damit kommt auch mein USB-powered Standard-NRF durch die Betondecke und etwas Wand in den ersten Stock; Keller-> 1. OG mit 2 PA-Modellen klappt auch. Ggf. müssen die #define PA_LEVEL... angepasst werden (hier war bei jemandem für das GW standardmäßig "LOW" eingestellt. Dann gibt es noch lustige Sachen wie angelötete Antennen usw. (Link müßte ich suchen), der Kondensator hat bei mir wenig gebracht, habe jetzt aber trotzdem einige Sockel hier liegen für zukünftige Projekte.
(Wäre vermutlich Zeit, die ganzen Beispiele und Erfahrungen etwas zu strukturieren und in's Wiki zu nehmen; die Seiten dazu bei Mysensors sind zwar klasse, aber englisch und nicht unbedingt FHEM-spezifisch (wie diese IR_SEND-Zuordnung usw.).
Zitat von: joe_re am 11 Mai 2016, 14:44:26
(Wäre vermutlich Zeit, die ganzen Beispiele und Erfahrungen etwas zu strukturieren und in's Wiki zu nehmen; die Seiten dazu bei Mysensors sind zwar klasse, aber englisch und nicht unbedingt FHEM-spezifisch (wie diese IR_SEND-Zuordnung usw.).
Wegen dem ir_send Mapping habe ich dem Ersteller des Moduls eine PM geschrieben. Das sollte am besten, genau wie das Mapping ir_receive, automatisch erzeugt werden. Meiner Meinung nach fehlt das beim autocreate.
Zitat von: r_knipp am 11 Mai 2016, 15:19:45
Wegen dem ir_send Mapping habe ich dem Ersteller des Moduls eine PM geschrieben. Das sollte am besten, genau wie das Mapping ir_receive, automatisch erzeugt werden. Meiner Meinung nach fehlt das beim autocreate.
Gut, da gehört es auf jeden Fall
auch hin!
Andererseits gibt es hier zwar sehr viel Info (das mit dem mapping war auch für mich schon mal ein Problem, als ich versucht habe, meinen Gas-Sensor als solchen anzulegen; ist jetzt halt ein Wasserzähler 8)). Aber alle Infos sind ziemlich verteilt und nicht besonders strukturiert. Und dann bist du der 2., der meine Erfahrungen bzgl. Reichweite zu hören bekommen hat...
Zitat von: r_knipp am 11 Mai 2016, 11:59:06
Hast du eigentlich mal die Reichweite deiner IR-Diode getestet?
So, Bauteile eben mal zusammengesteckt. Reichweite nach dem einfachen NPN-Bauplan aus https://learn.adafruit.com/using-an-infrared-library/sending-ir-codes und der Serial-Remote (aus der neuen IRLib) als Sketch: ca. 2,5m, direkte Sichtverbindung... Andere Tests (kein Widerstand, 3 bzw. 2 Dioden in Reihe waren eher schlechter.
Allerdings wollte irsend.send() (bzw. dort My_Sender.send(IR_types_t(... ) zunächst nicht so recht, erst als ich mein NEC in der Form My_Sender.send(IR_types_t(1), code, bits) übergeben habe, ging das kompilieren. Vorher dachte ich schon, die Diode (bzw. auch die 2.) wäre kaputt
So, es läuft endlich.
Beim Empfang übergebe ich einfach zur Info das Protokoll auch in Klartext.
Zum Senden muss das Protokoll als Zahl übergeben werden. Habe es einfach nicht als Klartext konvertiert bekommen aber das sollte ja kein Problem sein. Siehe Screenshot.
Habs auf GitHub geändert.
Zitat von: r_knipp am 11 Mai 2016, 23:11:35
So, es läuft endlich.
:) :) :) Super Job!!!
- Würde gerne noch die Reihenfolge beim Senden anders herum machen (Klartext nach hinten); wenn der Sendetext zu lang sein sollte, wird hinten abgeschnitten, was bei der Textinfo nicht so tragisch wäre. Einwände?
Da wir die ganzen seriellen Infos dann hoffentlich nicht mehr brauchen: #ifdef MY_DEBUG nutzen?
- Protokolle: Wenn ich dazu komme (Tendenz eher am WE), würde ich mal versuchen, PanasonicNew und Samsung32 einzupflegen, oder wird dein BenQ doch bereits erkannt? Die Lib habe ich mal geforked, kann dich gerne auch wieder als Editor zulassen?
- Gibt es erprobte Ideen, was die Reichweite der IR-Diode angeht? Ansonsten würde ich es erst mal mit den weiterführenden Links von Adafruit versuchen (ich habe nur drei "blanke" IR-Dioden, kein Modul).
Off IR-Topic:
Ach ja: habe noch eine Dunstabzugshaube, die wohl einen 433MHz-Code nutzt (den ich allerdings bisher nicht ernsthaft versucht habe zu decodieren, aber so steht es auf der FB). An sich müßte man die hier entwickelte FHEM<->MySensor-IR-Mimik doch auch nutzen können, um das Teil damit zu steuern, oder? Einen rudimentären Sketch dazu gibt es in der 2.0.0 beta (bislang nur für's Empfangen).
Zitat von: joe_re am 12 Mai 2016, 09:30:13
:) :) :) Super Job!!!
Danke :)
Zitat von: joe_re am 12 Mai 2016, 09:30:13
- Würde gerne noch die Reihenfolge beim Senden anders herum machen (Klartext nach hinten); wenn der Sendetext zu lang sein sollte, wird hinten abgeschnitten, was bei der Textinfo nicht so tragisch wäre. Einwände?
Nein, das ist ja egal. Wirklich brauchen tut man es ja nicht.
Zitat von: joe_re am 12 Mai 2016, 09:30:13
Da wir die ganzen seriellen Infos dann hoffentlich nicht mehr brauchen: #ifdef MY_DEBUG nutzen?
Ja klar, kann raus.
Zitat von: joe_re am 12 Mai 2016, 09:30:13
- Protokolle: Wenn ich dazu komme (Tendenz eher am WE), würde ich mal versuchen, PanasonicNew und Samsung32 einzupflegen, oder wird dein BenQ doch bereits erkannt? Die Lib habe ich mal geforked, kann dich gerne auch wieder als Editor zulassen?
Muss ich heute nochmal ausprobieren. Ich glaube das hatte ich noch gar nicht getestet.
Zitat von: joe_re am 12 Mai 2016, 09:30:13
- Gibt es erprobte Ideen, was die Reichweite der IR-Diode angeht? Ansonsten würde ich es erst mal mit den weiterführenden Links von Adafruit versuchen (ich habe nur drei "blanke" IR-Dioden, kein Modul).
Hab ich mich bisher noch nicht näher mit beschäftigt. Da der Code jetzt aber läuft ist es als nächstes dran.
Zitat von: joe_re am 12 Mai 2016, 09:30:13
Off IR-Topic:
Ach ja: habe noch eine Dunstabzugshaube, die wohl einen 433MHz-Code nutzt (den ich allerdings bisher nicht ernsthaft versucht habe zu decodieren, aber so steht es auf der FB). An sich müßte man die hier entwickelte FHEM<->MySensor-IR-Mimik doch auch nutzen können, um das Teil damit zu steuern, oder? Einen rudimentären Sketch dazu gibt es in der 2.0.0 beta (bislang nur für's Empfangen).
Das Prinzip sollte nach meinem Verständnis das gleiche sein. Halt nur eine andere Übertragungstechnik.
Zitat von: r_knipp am 12 Mai 2016, 09:48:38
Hab ich mich bisher noch nicht näher mit beschäftigt. Da der Code jetzt aber läuft ist es als nächstes dran.
Größere Leistung scheint kein Hexenwerk zu sein, siehe Anhang (aus der IRLib-Doku). Für den Fall, dass du keine Grabbelkiste mit Kleinteilen hast: ein paar NPN und PNP hätte ich über (die IRs brauche ich wohl selber) => PN...
So, Reihenfolge beim Senden getauscht, das #MY_DEBUG erledigt und den code nochmal um "Reste" gesäubert.
Nochmal: r_knipp: Super Job, klappt jetzt alles einwandfrei!!!!
Meine PNP-Versuche waren dagegen nicht so der Hit, war aber wohl etwas zu sehr in Eile....
Zitat von: joe_re am 12 Mai 2016, 20:11:03
Meine PNP-Versuche waren dagegen nicht so der Hit, war aber wohl etwas zu sehr in Eile....
hmm... eine LED ansteuern ist jetzt ja eigentlich kein Geheimnis. Ich werde nur leider erst wieder nächste Woche zu Tests kommen.
Schau mal hier: http://www.mikrocontroller.net/articles/Transistor#Wie_finde_ich_den_richtigen_Transistor_f.C3.BCr_eine_LED-Ansteuerung.3F
Die IR-LEDs kannst du gepulst, was ja hier der Fall ist, übrigens mit bis zu 1A betreiben.
Hallo,
Ich wollte mal mit mysensors ein LCD 20x4 anbinden, aber ich habe keine Syntax gefunden wie ich z.B. die Werte von meinem KS300 ans Display übermitteln kann.
Vielleicht hat ja jemand das mal gemacht oder einen Link?
Zitat von: Edi77 am 15 Mai 2016, 01:34:05
Hallo,
Ich wollte mal mit mysensors ein LCD 20x4 anbinden, aber ich habe keine Syntax gefunden wie ich z.B. die Werte von meinem KS300 ans Display übermitteln kann.
Vielleicht hat ja jemand das mal gemacht oder einen Link?
Keinen Link, aber eine Vermutung: Es sollte gehen. Das "Problem" ist nur, die anzuzeigenden Inhalte an die Node zu schicken und dort sinnvoll zu verarbeiten. Es sollte aber mit einem (oder mehreren) S_CUSTOM "Kindern" gehen. Damit sollten sich eigentlich jeweils 5 beliebige Inhalte (begrenzter Länge) hin- und herschicken lassen. (Habe aber keine Ahnung, ob die V_VARx irgendwie auf einen bestimmten Datentyp beschränkt sind; bei IR_SEND war Text kein Problem).
Beim Senden mußt du darauf achten, dass die Variable in FHEM bereits gemapped ist. Für unsere IR-Fernbedienung brauchte es z.B. noch
attr MYSENSOR_xxx mapReading_ir_send3 3 ir_send.
Tendenziell würde ich das ähnlich wie das HM-OLED-Display angehen, also den anzuzeigenden Inhalt auf einen oder mehrere Child-IDs legen und dann die Anweisung, welcher der Inhalte anzuzeigen ist auf eine andere (bzw. ggf. mehrere).
Wie man beim Empfangen nach der Child-ID sortiert, ist gut an den mehrfach-Relay-Beispielen zu sehen.
Inwieweit das den Arduino fordert, würde mich auch interessieren. (Habe für "irgendwann mal" auch ein grafisches SPI-LCD hier liegen, für den Fall, dass mir mal langweilig wird 8))
Zitat von: Edi77 am 15 Mai 2016, 01:34:05
Vielleicht hat ja jemand ...einen Link?
...doch noch ein Link: https://www.openhardware.io/view/23/In-wall-LCD-SwitchScene-controller-for-MySensors#tabs-source.
Da klappt zumindest die Abfrage der Uhrzeit aus dem Controller und die gleichzeitige Ansteuerung eines (Grafik-) Displays (+Temp + diverse Taster); aktiv was vom Controller versenden lassen, ist das was wir hier vor kurzem mit remotecontrol und IR gemacht haben, also per notify (wenn der KS etwas neues an FHEM gesendet hat. Zeitgesteuert ginge damit auch.
Bleibt die Frage, welche Variablentypen V_VARx sein dürfen, wenn man das mit S_CUSTOM verheiratet...
Zitat von: joe_re am 15 Mai 2016, 08:06:02
(Habe aber keine Ahnung, ob die V_VARx irgendwie auf einen bestimmten Datentyp beschränkt sind; bei IR_SEND war Text kein Problem).
Also nach meinem Verständnis spielt das keine Rolle. Wenn ich in FHEM ein Sende-Reading setze wird wahrscheinlich eh immer ein String verschickt.
Ich denke die Variablentypen sind nur zur Identifikation der Sensoren. Ein Node kann ja z.B. mehrere (bis zu 254) Sensoren haben.
Auf die entsprechenden Variablen kann man dann ja beliebige Readings mappen.
Im Sketch des Nodes kann ich dann abfragen von welchem Typ die empfangenen Daten sind.
if (message.type == V_TEXT)
und sie entsprechend unterschiedlich verarbeiten.
Für ein LCD gibt es in der 2.0 beta z.B. den Typen V_Text.
Zitat von: joe_re am 17 Mai 2016, 13:42:21
...doch noch ein Link: https://www.openhardware.io/view/23/In-wall-LCD-SwitchScene-controller-for-MySensors#tabs-source.
Hier empfängt er ja auch nur einen String mit dem Temperaturwert und zeigt ihn auf dem Display an.
Ich würde jetzt beim KS300 auch einfach einen String mit Temperatur und Windgeschwindigkeit (oder was das Teil noch kann) schicken und im Node zerlegen.
Worüber ich nichts gefunden habe ist, ob man ein Node z.B. mit S_INFO zu einem LCD Text Device machen kann und ihm statt V_TEXT mehrere V_VARx zuweisen kann, um Temperatur, Windgeschwindigkeit, etc. separat zu verschicken.
Müsste man mal nen Testsketch machen und schauen was FHEM draus macht.
Zitat von: r_knipp am 18 Mai 2016, 08:56:39
Also nach meinem Verständnis spielt das keine Rolle. Wenn ich in FHEM ein Sende-Reading setze wird wahrscheinlich eh immer ein String verschickt.
Hier empfängt er ja auch nur einen String mit dem Temperaturwert und zeigt ihn auf dem Display an.
Müsste man mal nen Testsketch machen und schauen was FHEM draus macht.
Sehe ich ähnlich. Tendenziell geht halt immer eine Folge von Bytes hin und her, wie das zu interpretieren ist, ist jeweils Sache des Controllers bzw. der Node. Dass der zitierte Sketch tatsächlich auch was empfängt, war mir ganz entgangen :o, ich hatte nur gesehen, dass da ein DS18B20 dran hängt...
Allerdings würde ich das Text-Processing und Formatwandlungen in der Node lieber vermeiden ::). Das geht zwar und @r_knipp: Klasse Demo, was da möglich ist 8). Bei einem LCD würde ich aber eher von FHEM aus direkt handhabbare Stücke liefern und dafür die Zahl der Variablen höher wählen (ähnlich wie das Registersetzen der HM-Displays, daher auch S_CUSTOM*n als Vorschlag, da hat man pro Child-ID jeweils die höchste Zahl der möglichen Bausteinchen/Variablen). Das sollte auch besser sein für den Speicherhunger des Sketches, oder?
Die Frage, an welches "S_CUSTOM[n]" sich die Controller-Message richtet, läßt sich bei der Message-Auswertung einfach über "message.sensor" abfragen.
Damit ließen sich auch Umschaltbefehle für das ganze Display codemäßig leichter trennen von "reinen" Inhalts-updates (z.B. S_CUSTOM[1] für Darstellungsanweisungen, S_CUSTOM[2-4] für welche Inhalte auch immer...
Was den Testsensor angeht: Bin sowieso dabei, mein nicht so richtig funktionierendes China-Bewegungsmelder-LED-Leuchtmittel in der Garage mit Hilfe eines Multisensors zu ersetzen. Der soll u.A. auch eine "echte" Bewegungsmelder-Funktionalität bekommen und dabei vom Controller aus konfigurierbar sein, was Einschaltdauer und Umgebungslicht angeht.
Erste Fragmente des Bewegungsmelders+ liegen auf Github, wenn's jemanden interessiert (Achtung: kein Display geplant und v.a. wg. des BMP180 recht unübersichtlich; da geht es zunächst mal "nur" um die Konfigurierbarkeit): https://github.com/rejoe2/MySensors-Garage.
Zitat von: joe_re am 18 Mai 2016, 11:21:00
Was den Testsensor angeht: Bin sowieso dabei, mein nicht so richtig funktionierendes China-Bewegungsmelder-LED-Leuchtmittel in der Garage mit Hilfe eines Multisensors zu ersetzen. Der soll u.A. auch eine "echte" Bewegungsmelder-Funktionalität bekommen und dabei vom Controller aus konfigurierbar sein, was Einschaltdauer und Umgebungslicht angeht.
Wenn du Lust hast könntest du dann ja auch mal ausprobieren, ob man sich nicht auch selber einen neuen Sensor definieren kann.
Ich würde fast wetten, dass man dafür nur die entsprechenden S_ und V_ sub-types in der MySensors.h definieren muss.
Zitat von: r_knipp am 18 Mai 2016, 12:59:03
Wenn du Lust hast könntest du dann ja auch mal ausprobieren, ob man sich nicht auch selber einen neuen Sensor definieren kann.
Ich würde fast wetten, dass man dafür nur die entsprechenden S_ und V_ sub-types in der MySensors.h definieren muss.
Es sollte tendenziell tatsächlich kein großes Problem sein, die Anzahl der Typen zu erhöhen (Definitionen stehen wohl in der /core/MyMessage.h). Allerdings könnte die Definition neuer Sensor-Typen im Sinne einer typischen Zusammenstellung von Informationen noch einfacher sein:
Wenn ich mich recht entsinne, hatte ich in der Vergangenheit hin und wieder beim Zusammenstricken der Sketche für Multi-Sensoren den "Fehler" gemacht, die Child-IDs diverser Hardware nicht sauber auseinanderzuhalten. MySensors meckerte da nicht rum. Was möglicherweise nicht funktioniert hat, ist das autocreate von FHEM (hab das alles natürlich wieder gelöscht, ist nicht mehr nachvollziehbar)....
Das ließe sich sicher durch das Aufbohren von MYSENSOR_DEVICE.pl oder manuelle Zuordnungen beheben; bleibt die Frage, ob das überhaupt Sinn macht :-\, wenn es mit "Bordmitteln" bereits ganz ordentlich funktionieren sollte (was sich nach meiner Erfahrung grundsätzlich besser mit updates verträgt).
Wo siehst Du den Vorteil eines "neuen" Sensortyps?
Zitat von: joe_re am 18 Mai 2016, 13:53:07
Das ließe sich sicher durch das Aufbohren von MYSENSOR_DEVICE.pl oder manuelle Zuordnungen beheben;
Ich glaube das ist gar nicht nötig. Wenn man die S_ und V_ sub-types richtig definiert.
Das Modul zieht sich sicher aus der presence message die sub-types und legt entsprechend auch die Readings an.
Dem ist bestimmt auch egal wie die genau heißen.
Zitat von: joe_re am 18 Mai 2016, 13:53:07
Wo siehst Du den Vorteil eines "neuen" Sensortyps?
Eigentlich wärs nur ganz interessant obs funktioniert ;-)
Ansonsten könnte man sich so ja nen eigenen Sensor bauen wenn die verfügbaren nicht passen. Vor allem bei Multisensoren.
Zitat von: r_knipp am 18 Mai 2016, 14:11:28
Ich glaube das ist gar nicht nötig. Wenn man die S_ und V_ sub-types richtig definiert.
Das Modul zieht sich sicher aus der presence message die sub-types und legt entsprechend auch die Readings an.
Dem ist bestimmt auch egal wie die genau heißen.
??? Also nach unseren Erfahrungen mit der IR_SEND-Geschichte würde ich steif und fest behaupten, dass FHEM per autocreate nur anlegt, was in MYSENSORS_DEVICE.p
m (sorry für den typo) sauber angelegt ist (bzw. nachträglich per "attr mapreading..." eingepflegt wird).
Und beide MS-perl-Module scheinen keine Übersetzung von Ziffern (Sendeprotokoll) nach Variablen (Klartextnamen) zu machen, das spuckt demnach das Gateway bereits rückübersetzt aus; das würde dann auch an der Stelle nach exakter Schreibweise bzw. Einhaltung der vorgegebenen Namen verlangen.
Zitat von: r_knipp am 18 Mai 2016, 14:11:28
Eigentlich wärs nur ganz interessant obs funktioniert ;-)
:) Genau darum ging's mir mit meinem konfigurierbaren Bewegungsmelder; ob man dazu jetzt noch eine Child-ID mehr oder weniger verbrät, ist m.E. nicht so wichtig ;D. Wenn es aber geht, sollte es praktisch auf alle Anwendungsfälle übertragbar sein, also z.B.
- das Info-LCD
- Bewegungsmelder+Relay/LED ohne eigenen Lichtsensor (Info dann über den Controller; da fällt mir doch gleich auch noch eine Stelle ein, wo das ohne großen Aufwand hilfreich wäre :)!!!)
- ....
Wenn ich das alles nur vorher halbwegs verstanden hätte ::)! Dann
- hätte ich nicht so oft in den Keller rennen müssen zum Nano-Wechseln :'(
- wäre manches DOIF gespart worden und diese Logikteile direkt im Arduino untergebracht ;D
- hätte es am Wochenende bestimmt draußen 10 Grad mehr gehabt ;)
Zitat von: joe_re am 18 Mai 2016, 15:25:20
??? Also nach unseren Erfahrungen mit der IR_SEND-Geschichte würde ich steif und fest behaupten, dass FHEM per autocreate nur anlegt, was in MYSENSORS_DEVICE.pm (sorry für den typo) sauber angelegt ist (bzw. nachträglich per "attr mapreading..." eingepflegt wird).
Ach ja, das gibt's ja auch noch. Sorry, hatte die ganze Zeit nur das Gateway Modul im Kopf und in dem hatte ich nichts sensorspezifisches gefunden.
Gerade mal reingeschaut. Du hast Recht. Das Device Modul müsste man erweitern.
Also vielleicht doch am besten custom. Eigentlich ist der Typ ja auch egal. Identifizieren kann man ihn ja über seinen Namen.
Ich frage mich allerdings noch wie das mit mehr als fünf Sensoren funktionieren soll. ???
Ein Node kann ja wohl 254 Sensoren. Kann man sich ja mal mit beschäftigen wenn mans denn braucht ;)
Zitat von: Edi77 am 15 Mai 2016, 01:34:05
Hallo,
Ich wollte mal mit mysensors ein LCD 20x4 anbinden, aber ich habe keine Syntax gefunden wie ich z.B. die Werte von meinem KS300 ans Display übermitteln kann.
Vielleicht hat ja jemand das mal gemacht oder einen Link?
Da hat jemand das Display-Problem schon gelöst; zu allem Überfluß auch noch mit FHEM als controller!!!!
https://forum.mysensors.org/topic/1817/weather-and-forecast-display-for-swedish-fhem-users/2
Und dann noch intensive Nutzung von PROGMEM und F zur Speicherung der Variablen! Sehr interessant :)
Unter der Child-ID 4 (S_SWITCH) findet sich dann auch noch mehrere V_VARn; die einfach gemapped sind; wäre interessant zu wissen, ob das FHEM-device-Modul angepaßt wurde oder ob das "einfach so" geht.
Zitat von: r_knipp am 18 Mai 2016, 15:45:56
Ich frage mich allerdings noch wie das mit mehr als fünf Sensoren funktionieren soll. ???
Also die pure Zahl der Sensoren ist nach meiner Erfahrung kein Problem an sich; ich habe derzeit 2 Nodes, die 5 und mehr Kinder haben; da kommen geplant min. noch 2 dazu. Da wird dann eher die Größe des Speichers zum Thema (daher auch gerne #ifdef MY_DEBUG).
Zitat von: joe_re am 18 Mai 2016, 16:59:58
Also die pure Zahl der Sensoren ist nach meiner Erfahrung kein Problem an sich; ich habe derzeit 2 Nodes, die 5 und mehr Kinder haben; da kommen geplant min. noch 2 dazu. Da wird dann eher die Größe des Speichers zum Thema (daher auch gerne #ifdef MY_DEBUG).
OK, habe mir auch mal das schwedische Beispiel angeschaut. Jetzt verstehe ich es. Der einzelne Sensor eines Nodes wird über CHILD_ID identifiziert und jeder Sensor kann wieder mehrere Variablen, z.B. V_VARx, für Messwerte haben.
Auf Hackaday gefunden.
Vielleicht ja für jemanden interessant.
Reichweitenerhöhung beim NRF24l01+
http://blog.blackoise.de/2016/02/fixing-your-cheap-nrf24l01-palna-module/
Hallo,
habe mir jetzt vor auch den ersten Sensor Fensterkontakt mit Reed Kontakt zusammen gebaut. Hat auch alles soweit Problemlos funktioniert.
:D
Mein MySensor Device Zeigte nun nur an 771751936 = Tür zu und 771751937 = Tür auf.
Kann mir jemand erklären wie ich dem Sensor ein einfaches On OFF beibringen kann.
Danke
Eigentlich sollte der doch nur 1 oder 0 übermitteln.
Lösch mal das Attribut stateFormat.
Ich gehe davon aus, dass du im Moment das gleiche Problem hast wie viele mit der neuen Beta-Version von der MySensors Bibliothek. Ich habe bei meinen Temperaturwerte ähnliche Fehler gehabt mit einem WLAN Gateway.
Bei mir hat es geholfen, die ESP8266 Bibliothek in der Arduino IDE auf 2.2 zu stellen.
Zitat von: gloob am 13 Juni 2016, 10:06:51
Ich gehe davon aus, dass du im Moment das gleiche Problem hast wie viele mit der neuen Beta-Version von der MySensors Bibliothek.
Dem Screenshot nach nutzt er die 1.5.4
Zitat von: gloob am 13 Juni 2016, 10:06:51
Bei mir hat es geholfen, die ESP8266 Bibliothek in der Arduino IDE auf 2.2 zu stellen.
MySensors nutzt aber keinen ESP8266.
Ausweislich des screenshots scheint torte eher noch das 1.5.4-Framework zu nutzen.
@Torte: Es fehlen leider wichtige Informationen zu Deinem Umfeld (MySensors-Version, welche Art GW, ob ggf. sogar MQTT eingesetzt wird (und wo). Bitte liefere das nach, sonst verleitest Du alle, die Dir helfen wollen zu Spekulationen.
Zitat von: r_knipp am 01 Juni 2016, 12:42:17
Auf Hackaday gefunden.
Vielleicht ja für jemanden interessant.
Reichweitenerhöhung beim NRF24l01+
http://blog.blackoise.de/2016/02/fixing-your-cheap-nrf24l01-palna-module/
Hallo r_knipp: habe das in die "Sammlung" für das Wiki mit aufgenommen, hoffe das war ok.
Und: Ich habe zwar den IR-Blaster (4-fach) nach Ken's Anleitung zusammengelötet, aber die Reichweite ist noch nicht so, wie sie sein sollte (der "Blaster" funktioniert aber grundsätzlich, die Reichweite war 2-fach sogar ziemlich ok, verwendet habe ich billige Standard-Transistoren). Da hier Leute sind, die sich mit den elektrischen Themen vielleicht leichter tun: Kann es sein, dass der Blaster nicht genug Strom ziehen kann und hilft es ggf., einfach einen Kondensator zur Spannungsstabilisierung zu verwenden? Welche Kapazität ca.?
Und: Mein Versuch, die beiden fehlenden Protokolle für die IR-Sache mit aufzunehmen, war leider nicht erfolgreich, ich konnte es nicht kompilieren... Da ich aber sowieso im Raum bin, wenn der Beamer läuft, werde ich daran jetzt erst mal nicht weiterwursteln.
Hallo,
vielen Dank schon mal für die Hilfe. Das Attribut stateFormat hab ich schon mal gelöscht.
Kann das aber zur Zeit nicht testen da ich nicht zuhause bin und keiner durch die Tür geht. ;D
Bei der Version von MySensors, habe meiner Meinung nach, die 1.5. Bin aber nicht zuhause, muss ich also nochmal nachliefern.
Das GW ist aber ein WLAN mit nodeMCU.
Vielen Dank !!
Was für ein Gateway benutzt du denn? Seriell oder WLAN?
Hi gloob,
nodeMCU mit WLAN Gateway
Grüße
Torte
Dann auf jeden Fall mal das Gateway auf die aktuelle Developement Version umstellen. NodeMCU ist auch eine ESP8266 Variante und dort gibt es aktuell mit der 1.5 Probleme.
Zitat von: Hauswart am 13 Juni 2016, 10:58:08
Dann auf jeden Fall mal das Gateway auf die aktuelle Developement Version umstellen. NodeMCU ist auch eine ESP8266 Variante und dort gibt es aktuell mit der 1.5 Probleme.
Danke für die Klarstellung, das scheint wirklich vielen Leuten völlig unbekannt zu sein.
Also: MySensors-framework updaten auf 2.0.0-beta, den ESP-Teil in der Arduino IDE (so er sie benutzt) ebenfalls auf den aktuellen Stand bringen, und dann mal sehen, was passiert...
Eine Bitte: Wenn Ihr zu dem Thema allgemein interessante Dinge bemerkt habt, wäre es evtl. gut, das halbwegs sinnvoll aufbereitet hier zur Verfügung zu stellen: https://forum.fhem.de/index.php/topic,51325.msg429876.html#msg429876. Dieser Thread hier ist schon wirklich lang...
Viel Erfolg!
Sorry das ich nachfrage.
Ich muss also diese libraries https://github.com/mysensors/Arduino downloaden, installieren
den Sketch neu kompilieren und dann wieder in den NodeMCU laden.
Zitat von: Beta-User am 13 Juni 2016, 10:19:15
Hallo r_knipp: habe das in die "Sammlung" für das Wiki mit aufgenommen, hoffe das war ok.
Ja sicher.
Zitat von: Beta-User am 13 Juni 2016, 10:19:15
Und: Ich habe zwar den IR-Blaster (4-fach) nach Ken's Anleitung zusammengelötet, aber die Reichweite ist noch nicht so, wie sie sein sollte (der "Blaster" funktioniert aber grundsätzlich, die Reichweite war 2-fach sogar ziemlich ok, verwendet habe ich billige Standard-Transistoren). Da hier Leute sind, die sich mit den elektrischen Themen vielleicht leichter tun: Kann es sein, dass der Blaster nicht genug Strom ziehen kann und hilft es ggf., einfach einen Kondensator zur Spannungsstabilisierung zu verwenden? Welche Kapazität ca.?
Da bin ich leider noch nicht zu gekommen. Aber irgendwie muss das vernünftig gehen. Bei den Fernbedienungen meines Receivers und der VU+ Uno ist es sogar egal ob ich sie auf das Gerät richte oder vom Gerät weg. Bestelle die Tage bei Reichelt dann kommen auch IR-Dioden mit. Dann werde ich mal testen.
Zitat von: Beta-User am 13 Juni 2016, 10:19:15
Und: Mein Versuch, die beiden fehlenden Protokolle für die IR-Sache mit aufzunehmen, war leider nicht erfolgreich, ich konnte es nicht kompilieren... Da ich aber sowieso im Raum bin, wenn der Beamer läuft, werde ich daran jetzt erst mal nicht weiterwursteln.
Bei meinem Beamer ist es NEC. Bis auf eine Taste, die er nicht erkannt hat.
Das Problem ist aber, zum Ausschalten muss man zweimal auf OFF drücken. Das kann man ja sicher noch in FHEM programmieren. Aber für die Eingangswahl gibt es keine direkten Tasten. Man muss so oft auf SOURCE drücken bis man den gewünschten Eingang hat oder das Gerät findet die Quelle automatisch. Das ist ungünstig, da FHEM ja nicht weiß auf welchen Eingang der Beamer gerade eingestellt ist. Daher werde ich mich wohl man weiter mit ESP8266 Serial Bridge beschäftigen.
Zitat von: r_knipp am 13 Juni 2016, 12:22:49
Bei meinem Beamer ist es NEC.
Coole Sache, dann war es einfacher als gedacht!
Zitat von: r_knipp am 13 Juni 2016, 12:22:49
Bis auf eine Taste, die er nicht erkannt hat.
Das Problem ist aber, zum Ausschalten muss man zweimal auf OFF drücken. Das kann man ja sicher noch in FHEM programmieren. Aber für die Eingangswahl gibt es keine direkten Tasten. Man muss so oft auf SOURCE drücken bis man den gewünschten Eingang hat oder das Gerät findet die Quelle automatisch. Das ist ungünstig, da FHEM ja nicht weiß auf welchen Eingang der Beamer gerade eingestellt ist. Daher werde ich mich wohl man weiter mit ESP8266 Serial Bridge beschäftigen.
Irgendwo im LIRC-Umfeld habe ich mal gelesen, dass es teilweise undokumentierte Codes gibt, um die Sourcen direkt zu schalten usw., allerdings habe ich da keinerlei praktische Erfahrung. Das heißt in etwa: es exisiterent mehr FB-Codes, als Tasten auf der Fernbedienung vorhanden sind, man muß sie nur kennen, dann werden sie evtl. auch vom Beamer erkannt und ordnungsgemäß verarbeitet ::).
Als Ansatzpunkt könnten evtl. die LIRC.conf-Infos dienen, die im Web zu BenQ-Beamern zu finden sind. Du müßtest dann "nur" die entsprechenden Sendecodes manuell mal testen bzw. erraten. Es scheint auch so zu sein, dass die undokumentierten Codes in der Regel nummerisch unmittelbar vor oder hinter dem Code für den Sourcenwechsel zu finden sind.
Ein Beispiel (insbes. Post 5 und 6 (evtl. auch 4, der aber nur raw-Infos aufzählt)): http://www.remotecentral.com/cgi-bin/mboard/rc-discrete/thread.cgi?7297. Dort gibt es auch dezidierte Codes für "on" und "off".
Zitat von: Beta-User am 13 Juni 2016, 13:37:08
Ein Beispiel (insbes. Post 5 und 6 (evtl. auch 4, der aber nur raw-Infos aufzählt)): http://www.remotecentral.com/cgi-bin/mboard/rc-discrete/thread.cgi?7297. Dort gibt es auch dezidierte Codes für "on" und "off".
Ach, das ist ja cool. Besten Dank für den Tip. Werde das mal ausprobieren.
Hallo zusammen,
Vielen Dank.
Habe jetzt auf dem NodeMCU Wlan Gateway die MySensors Beta Library 2.0.0. Der TürSensor meldet nun wunderbar on off :).
Habe aber zwei fragen.
1.)Angefangen hatte ich mit dem Sketch von Hexenmeister v1.0.1 und MySensors Library 1.5.4, beim kompilieren mit diesem Sketch kommt
es aber zu einem Fehler. Habe dann einfach den Mysensors GatewayESP8266 Sketch genommen mit diesem ging es dann ohne Probleme.
Ist das so okey? Weiß nicht ganz wofür die Anpassungen von Hexenmeister waren/sind.
2.)Wenn ich das Gateway vom Strom trenne und wieder verbinde, muss ich in FHEM erst beim Gateway auf Set Connect klicken damit
die Sensoren funktionieren, soll das so?
Vielen Dank noch mal für die freundliche Hilfe.
Schöne Grüße
Torte
Zitat von: torte am 13 Juni 2016, 17:43:00
1.)Angefangen hatte ich mit dem Sketch von Hexenmeister v1.0.1 und MySensors Library 1.5.4, beim kompilieren mit diesem Sketch kommt
es aber zu einem Fehler. Habe dann einfach den Mysensors GatewayESP8266 Sketch genommen mit diesem ging es dann ohne Probleme.
Ist das so okey? Weiß nicht ganz wofür die Anpassungen von Hexenmeister waren/sind.
In der alten Version waren Zeilenumbrüche so, dass FHEM diese nicht verstand. In der neueren scheint auch so zu gehen.
Zitat von: torte am 13 Juni 2016, 17:43:00
2.)Wenn ich das Gateway vom Strom trenne und wieder verbinde, muss ich in FHEM erst beim Gateway auf Set Connect klicken damit
die Sensoren funktionieren, soll das so?
FHEM verbindet sich nicht zwischendurch von alleine mit dem Gateway. Du kannst das aber z.B. per AT-Befehl tun.
Hallo Hexenmeiser, hallo alle anderen :D
vielen Dank für die Erklärung.
AT habe ich bei mir jetzt eingerichtet, so das bei einem Fhemstart der Connect durchgeführt wird. Da bei mir das Gateway an der selben Stromquelle hängt wie der Raspi
reicht das ja dann so bei mir.(Wegen evtl. Stromausfall)
Danke an alle für die Aufklärung und Hilfe.
Grüße
Torte
Bei FHEM-Start brauchst Du eigentlich keinen Connect, dieser passiert einmalig automatisch. Ein Neu-Connect brauchst du dann, wenn Gateway im laufenden Betrieb neugestartet wird.
Noch besser :) Hatte das so (Fhem neustart) nicht ausprobiert. Danke!
Zitat von: torte am 14 Juni 2016, 07:37:22
Da bei mir das Gateway an der selben Stromquelle hängt wie der Raspi
reicht das ja dann so bei mir.(Wegen evtl. Stromausfall)
Hallo torte,
eine Frage interessehalber: wenn sich beide Geräte in unmittelbarer Nähe zueinander befinden, warum verwendest Du dann ein WLAN-GW und kein serielles? Planst Du den ESP8266/NodeMCU zukünftig auch als MQTT-Broker zu nutzen, oder hattest Du ihn einfach daliegen bzw. gerade keinen Arduino zur Hand?
Hi Beta-User,
das NodeMCU ist zur Zeit bei mir neben dem Raspi (oben im Büro, Speicher) an der Steckerleiste ich plane aber die Sensoren im ganzen Haus zu verteilen
(nach und nach) und da hab ich mir gedacht ist es am besten wenn ich das Gateway später dann in der Mitte des Hauses
je nach Empfangslage platziere. Da fand ich das WLan Gateway als beste Möglichkeit.
Auf die Sachen mit dem MQTT und Easy ESP bin ich gestern erst gestoßen, als ich mich nach dem MySensors Beta umgeschaut habe.
Da muss ich mich aber erstmal schlau machen, hab das noch nicht ganz geblickt, wie das mit den Sensoren usw. läuft.
Grüße
Torte
Zitat von: torte am 14 Juni 2016, 08:54:23
Hi Beta-User,
das NodeMCU ist zur Zeit bei mir neben dem Raspi (oben im Büro, Speicher) an der Steckerleiste ich plane aber die Sensoren im ganzen Haus zu verteilen
(nach und nach) und da hab ich mir gedacht ist es am besten wenn ich das Gateway später dann in der Mitte des Hauses
je nach Empfangslage platziere. Da fand ich das WLan Gateway als beste Möglichkeit.
Auf die Sachen mit dem MQTT und Easy ESP bin ich gestern erst gestoßen, als ich mich nach dem MySensors Beta umgeschaut habe.
Da muss ich mich aber erstmal schlau machen, hab das noch nicht ganz geblickt, wie das mit den Sensoren usw. läuft.
Grüße
Torte
OK, das ist plausibel mit der Funkabdeckung, den Gedanken hatte ich früher auch mal.
Andererseits könntest Du als Alternative dazu auch bei Bedarf eine/mehrere der Nodes als Repeater definieren (die dürfen halt nicht schlafen). Das mache ich im Moment so mit meinen "Keller"-Nodes, da hat eine einen NRF+ mit externer Antenne und bindet den Rest im UG/Außenbereich an, allerdings sind es noch nicht viele Nodes (dafür aber idR. mehrere Sensoren pro Node).
Wenn Du
kein MQTT nutzen möchtest bzw. brauchst, halte ich den Weg über die Repeater und einem seriellen GW mittlerweile für robuster: (Jedenfalls bei mir) sind weniger Geräte in die gesamte Übertragungsstrecke eingebunden (mein WLAN macht die FB, und ich hätte auch Skrupel, den Sensorik-Teil über dasselbe WLAN-Netz laufen zu lassen wie den "normalen" Datenverkehr). Dazu müßte ich aber meinen RPi tauschen bzw. aufrüsten und konfigurieren, und das ist mir im Moment schlicht zu viel, obwohl auch das sicher keine große Sache wäre...
Grundsätzlich hatte ich das große Problem, dass ich die NRF+ überschätzt habe, was die Funkabdeckung angeht, aber dazu gibt es u.A. hier im Forum mittlerweile einige interessante Tipps, wie man dem beikommen kann (wenn auch nicht alle erprobt zu sein scheinen). 8)
Hier, ich hab mal eine Frage, ich habe mir alles an Material für die MySensors geschichten gekauft und versuche gerade leidlich die Software zu installieren. Ich bekomme nichtmal den Gateway ans laufen...
Ich habe arduino IDE und die libaries (MySensors 2.0 und 1.5, beides jeweils einzeln versucht) installiert, die werden auch alle korrekt erkannt und im IDE angezeigt.
Ich habe einen Arduino UNO mit W5100 Ethernet Shield und einem NRF24L01.
Wenn ich den Scetch von der MySensors Homepage nehme, alles so verkabel wie auf der homepage geschrieben bekomme ich beim kompilieren ständig die fehlermeldung MySigningNone.h: No such file or directory. quottiere ich das aus, gehts mit der nächsten datei weiter die im include steht.
nehme ich in der IDE den beispiel sketch für Ethernet Gateway, klappt das hochladen, aber die verkabelung wie auf der webseite geschrieben stimmt nicht und im serial monitor kommt nur kauderwelsch. passe ich die pins im sketch an (Der uno hat ja keinen pin 16), erhalte ich folgenden Fehlercode
Zitat0;255;3;0;9;Starting gateway (RNNGA-, 2.0.0)
0;255;3;0;9;TSM:INIT
0;255;3;0;9;TSM:RADIO:OK
0;255;3;0;9;TSM:GW MODE
0;255;3;0;9;TSM:READY
IP: 192.168.5.223
0;255;3;0;9;No registration required
0;255;3;0;9;Init complete, id=0, parent=0, distance=0, registration=1
0;255;3;0;9;TSP:MSG:READ 0-0-0 s=0,c=0,t=0,pt=0,l=0,sg=0:
0;255;3;0;9;!TSP:MSG:PVER mismatch
0;255;3;0;9;TSP:MSG:READ 0-0-0 s=0,c=0,t=0,pt=0,l=0,sg=0:
0;255;3;0;9;!TSP:MSG:PVER mismatch
0;255;3;0;9;TSP:MSG:READ 0-0-0 s=0,c=0,t=0,pt=0,l=0,sg=0:
weiß da jemand weiter? :(
Hat sich erledigt, kabel waren doch falsch angepinnt... Schande über mich...
Ich könnte einen Tipp gebrauchen zu diesen Einträgen im FHEM Log:
Zitat2016.07.21 15:00:13 3: MYSENSORS: ignoring internal-msg from unknown radioId 101, childId 255 for
2016.07.21 15:00:19 3: MYSENSORS: ignoring internal-msg from unknown radioId 101, childId 255 for
2016.07.21 15:00:25 3: MYSENSORS: ignoring internal-msg from unknown radioId 101, childId 255 for
2016.07.21 15:00:31 3: MYSENSORS: ignoring internal-msg from unknown radioId 101, childId 255 for
2016.07.21 15:01:22 3: MYSENSORS: ignoring internal-msg from unknown radioId 101, childId 255 for
2016.07.21 15:01:33 3: MYSENSORS: ignoring internal-msg from unknown radioId 101, childId 255 for
Ich bin dazu zurück auf einen fertigen Stand eines Sensors:
/**
* The MySensors Arduino library handles the wireless radio link and protocol
* between your home built sensors/actuators and HA controller of choice.
* The sensors forms a self healing radio network with optional repeaters. Each
* repeater and gateway builds a routing tables in EEPROM which keeps track of the
* network topology allowing messages to be routed to nodes.
*
* Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
* Copyright (C) 2013-2015 Sensnology AB
* Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors
*
* Documentation: http://www.mysensors.org
* Support Forum: http://forum.mysensors.org
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* version 2 as published by the Free Software Foundation.
*
*******************************
*
* REVISION HISTORY
* Version 1.0 - Henrik Ekblad
*
* DESCRIPTION
* Weather station sensor example using BMP085 and DHT-11 or DHT-22 module
* http://www.mysensors.org/build/pressure
* http://www.mysensors.org/build/humidity
*
* WIRING
* DHT Sensor
* PIN2 D3 Arduino
* 10k resistor between PIN1 and PIN2
*
* BMP Sensor
* SCL A5 Arduino
* SDA A4 Arduino
*/
// Enable debug prints to serial monitor
//#define MY_DEBUG
// Enable and select radio type attached
#define MY_RADIO_NRF24
//#define MY_RADIO_RFM69
#include <SPI.h>
#include <MySensors.h>
#include <Wire.h>
#include <Adafruit_BMP085.h>
#include <DHT.h>
#include <BH1750.h>
// Set this to true if you want to send values altough the values did not change.
// This is only recommended when not running on batteries.
const bool SEND_ALWAYS = true;
// Adapt this constant: set it to the altitude above sealevel at your home location.
const float SEALEVEL = 688; // meters above sealevel
// Constant for the world wide average pressure
const float SEALEVEL_PRESSURE = 1013.25;
// ----------------------------------------------------------------------------
// Child sensor ids
#define CHILD_ID_BARO 0
#define CHILD_ID_TEMP1 1
#define CHILD_ID_HUM 2
#define CHILD_ID_TEMP2 3
// ----------------------------------------------------------------------------
// DHT-11/22
#define HUMIDITY_SENSOR_DIGITAL_PIN 3
DHT dht;
float lastTemp;
float lastHum;
boolean metric = true;
MyMessage msgHum(CHILD_ID_HUM, V_HUM);
MyMessage msgTemp(CHILD_ID_TEMP2, V_TEMP);
// ----------------------------------------------------------------------------
// BMP085
unsigned long SLEEP_TIME1 = 30000; // 1 minute required for forecast algorithm
unsigned long SLEEP_TIME2 = 30000; // 1 minute required for forecast algorithm
Adafruit_BMP085 bmp = Adafruit_BMP085(); // Digital Pressure Sensor
/*
DP/Dt explanation
0 = "Stable Weather Pattern"
1 = "Slowly rising Good Weather", "Clear/Sunny "
2 = "Slowly falling L-Pressure ", "Cloudy/Rain "
3 = "Quickly rising H-Press", "Not Stable"
4 = "Quickly falling L-Press", "Thunderstorm"
5 = "Unknown (More Time needed)
*/
const char *weatherStrings[] = { "stable", "sunny", "cloudy", "unstable", "thunderstorm", "unknown" };
enum FORECAST
{
STABLE = 0, // Stable weather
SUNNY = 1, // Slowly rising HP stable good weather
CLOUDY = 2, // Slowly falling Low Pressure System, stable rainy weather
UNSTABLE = 3, // Quickly rising HP, not stable weather
THUNDERSTORM = 4, // Quickly falling LP, Thunderstorm, not stable
UNKNOWN = 5 // Unknown, more time needed
};
const char *situationStrings[] = { "very low", "low", "normal", "high", "very high" };
enum WEATHER_SITUATION
{
VERY_LOW_PRESSURE = 0, // p > -7.5hPa
LOW_PRESSURE = 1, // p > -2.5hPa
NORMAL_PRESSURE = 2, // p < +/-2.5hPa
HIGH_PRESSURE = 3, // p > +2.5hPa
VERY_HIGH_PRESSURE = 4, // p > +7.5hPa
};
float lastPressure = -1;
float lastPressureTemp = -1;
int lastForecast = -1;
int lastSituation = NORMAL_PRESSURE;
const int LAST_SAMPLES_COUNT = 5;
float lastPressureSamples[LAST_SAMPLES_COUNT];
// get kPa/h be dividing hPa by 10
#define CONVERSION_FACTOR (1.0/10.0)
int minuteCount = 0;
bool firstRound = true;
// average value is used in forecast algorithm.
float pressureAvg;
// average after 2 hours is used as reference value for the next iteration.
float pressureAvg2;
float dP_dt;
MyMessage tempMsg(CHILD_ID_TEMP1, V_TEMP);
MyMessage pressureMsg(CHILD_ID_BARO, V_PRESSURE);
MyMessage forecastMsg(CHILD_ID_BARO, V_FORECAST);
MyMessage situationMsg(CHILD_ID_BARO, V_VAR1);
MyMessage forecastMsg2(CHILD_ID_BARO, V_VAR2);
void initPressureSensor()
{
if (!bmp.begin())
{
Serial.println(F("Could not find a valid BMP085 sensor, check wiring!"));
while (1) {}
}
}
void initHumiditySensor()
{
dht.setup(HUMIDITY_SENSOR_DIGITAL_PIN);
}
void setup()
{
initPressureSensor();
initHumiditySensor();
metric = getConfig().isMetric;
}
void presentation()
{
sendSketchInfo("Weather Station Sensor", "1.0");
present(CHILD_ID_BARO, S_BARO);
present(CHILD_ID_TEMP1, S_TEMP);
present(CHILD_ID_HUM, S_HUM);
present(CHILD_ID_TEMP2, S_TEMP);
}
int getWeatherSituation(float pressure)
{
int situation = NORMAL_PRESSURE;
float delta = pressure - SEALEVEL_PRESSURE;
if (delta > 7.5)
{
situation = VERY_HIGH_PRESSURE;
}
else if (delta > 2.5)
{
situation = HIGH_PRESSURE;
}
else if (delta < -7.5)
{
situation = VERY_LOW_PRESSURE;
}
else if (delta < -2.5)
{
situation = LOW_PRESSURE;
}
else
{
situation = NORMAL_PRESSURE;
}
return situation;
}
// The BMP provides a temperature value, too!
bool updatePressureSensor()
{
bool changed = false;
//sealevel pressure p0 from absolute pressure.
float pressure = bmp.readSealevelPressure(SEALEVEL) / 100.0;
float temperature = bmp.readTemperature();
if (!metric)
{
// Convert to fahrenheit
temperature = temperature * 9.0 / 5.0 + 32.0;
}
int forecast = sample(pressure);
int situation = getWeatherSituation(pressure);
if (SEND_ALWAYS || (temperature != lastPressureTemp))
{
changed = true;
lastPressureTemp = temperature;
#ifdef MY_DEBUG
Serial.print(F("Temperature = "));
Serial.print(temperature);
Serial.println(metric ? F(" *C") : F(" *F"));
#endif
if (!send(tempMsg.set(lastPressureTemp, 1)))
{
lastPressureTemp = -1.0;
}
}
if (SEND_ALWAYS || (pressure != lastPressure))
{
changed = true;
lastPressure = pressure;
#ifdef MY_DEBUG
Serial.print(F("sealevel Pressure = "));
Serial.print(pressure);
Serial.println(F(" hPa"));
#endif
if (!send(pressureMsg.set(lastPressure, 1)))
{
lastPressure = -1.0;
}
}
if (SEND_ALWAYS || (forecast != lastForecast))
{
changed = true;
lastForecast = forecast;
#ifdef MY_DEBUG
Serial.print(F("Forecast = "));
Serial.println(weatherStrings[forecast]);
#endif
if (send(forecastMsg.set(weatherStrings[lastForecast])))
{
if (!send(forecastMsg2.set(lastForecast)))
{
}
}
else
{
lastForecast = -1.0;
}
}
if (SEND_ALWAYS || (situation != lastSituation))
{
changed = true;
lastSituation = situation;
#ifdef MY_DEBUG
Serial.print(F("Situation = "));
Serial.println(situationStrings[situation]);
#endif
if (!send(situationMsg.set(lastSituation, 0)))
{
lastSituation = -1.0;
}
}
return changed;
}
// The dht provides a temperature, too!
bool updateHumiditySensor()
{
bool changed = false;
float temperature = dht.getTemperature();
float humidity = dht.getHumidity();
if (!isnan(temperature))
{
if (SEND_ALWAYS || (temperature != lastTemp))
{
lastTemp = temperature;
if (!metric)
{
temperature = dht.toFahrenheit(temperature);
}
changed = true;
#ifdef MY_DEBUG
Serial.print(F("T: "));
Serial.println(temperature);
#endif
if (!send(msgTemp.set(temperature, 1)))
{
lastTemp = -1.0;
}
}
}
else
{
Serial.println(F("Failed reading temperature from DHT"));
}
if (!isnan(humidity))
{
if (SEND_ALWAYS || (humidity != lastHum))
{
lastHum = humidity;
changed = true;
#ifdef MY_DEBUG
Serial.print(F("H: "));
Serial.println(humidity);
#endif
if (!send(msgHum.set(lastHum, 1)))
{
lastHum = -1.0;
}
}
}
else
{
Serial.println(F("Failed reading humidity from DHT"));
}
return changed;
}
void loop()
{
updatePressureSensor();
sleep(SLEEP_TIME1);
updateHumiditySensor();
sleep(SLEEP_TIME2);
}
float getLastPressureSamplesAverage()
{
float lastPressureSamplesAverage = 0;
for (int i = 0; i < LAST_SAMPLES_COUNT; i++)
{
lastPressureSamplesAverage += lastPressureSamples[i];
}
lastPressureSamplesAverage /= LAST_SAMPLES_COUNT;
// Uncomment when dubugging
//Serial.print(F("### 5min-Average:"));
//Serial.print(lastPressureSamplesAverage);
//Serial.println(F(" hPa"));
return lastPressureSamplesAverage;
}
// Algorithm found here
// http://www.freescale.com/files/sensors/doc/app_note/AN3914.pdf
// Pressure in hPa --> forecast done by calculating kPa/h
int sample(float pressure)
{
// Calculate the average of the last n minutes.
int index = minuteCount % LAST_SAMPLES_COUNT;
lastPressureSamples[index] = pressure;
minuteCount++;
if (minuteCount > 185)
{
minuteCount = 6;
}
if (minuteCount == 5)
{
pressureAvg = getLastPressureSamplesAverage();
}
else if (minuteCount == 35)
{
float lastPressureAvg = getLastPressureSamplesAverage();
float change = (lastPressureAvg - pressureAvg) * CONVERSION_FACTOR;
if (firstRound) // first time initial 3 hour
{
dP_dt = change * 2; // note this is for t = 0.5hour
}
else
{
dP_dt = change / 1.5; // divide by 1.5 as this is the difference in time from 0 value.
}
}
else if (minuteCount == 65)
{
float lastPressureAvg = getLastPressureSamplesAverage();
float change = (lastPressureAvg - pressureAvg) * CONVERSION_FACTOR;
if (firstRound) //first time initial 3 hour
{
dP_dt = change; //note this is for t = 1 hour
}
else
{
dP_dt = change / 2; //divide by 2 as this is the difference in time from 0 value
}
}
else if (minuteCount == 95)
{
float lastPressureAvg = getLastPressureSamplesAverage();
float change = (lastPressureAvg - pressureAvg) * CONVERSION_FACTOR;
if (firstRound) // first time initial 3 hour
{
dP_dt = change / 1.5; // note this is for t = 1.5 hour
}
else
{
dP_dt = change / 2.5; // divide by 2.5 as this is the difference in time from 0 value
}
}
else if (minuteCount == 125)
{
float lastPressureAvg = getLastPressureSamplesAverage();
pressureAvg2 = lastPressureAvg; // store for later use.
float change = (lastPressureAvg - pressureAvg) * CONVERSION_FACTOR;
if (firstRound) // first time initial 3 hour
{
dP_dt = change / 2; // note this is for t = 2 hour
}
else
{
dP_dt = change / 3; // divide by 3 as this is the difference in time from 0 value
}
}
else if (minuteCount == 155)
{
float lastPressureAvg = getLastPressureSamplesAverage();
float change = (lastPressureAvg - pressureAvg) * CONVERSION_FACTOR;
if (firstRound) // first time initial 3 hour
{
dP_dt = change / 2.5; // note this is for t = 2.5 hour
}
else
{
dP_dt = change / 3.5; // divide by 3.5 as this is the difference in time from 0 value
}
}
else if (minuteCount == 185)
{
float lastPressureAvg = getLastPressureSamplesAverage();
float change = (lastPressureAvg - pressureAvg) * CONVERSION_FACTOR;
if (firstRound) // first time initial 3 hour
{
dP_dt = change / 3; // note this is for t = 3 hour
}
else
{
dP_dt = change / 4; // divide by 4 as this is the difference in time from 0 value
}
pressureAvg = pressureAvg2; // Equating the pressure at 0 to the pressure at 2 hour after 3 hours have past.
firstRound = false; // flag to let you know that this is on the past 3 hour mark. Initialized to 0 outside main loop.
}
int forecast = UNKNOWN;
if (minuteCount < 35 && firstRound) //if time is less than 35 min on the first 3 hour interval.
{
forecast = UNKNOWN;
}
else if (dP_dt < (-0.25))
{
forecast = THUNDERSTORM;
}
else if (dP_dt > 0.25)
{
forecast = UNSTABLE;
}
else if ((dP_dt > (-0.25)) && (dP_dt < (-0.05)))
{
forecast = CLOUDY;
}
else if ((dP_dt > 0.05) && (dP_dt < 0.25))
{
forecast = SUNNY;
}
else if ((dP_dt >(-0.05)) && (dP_dt < 0.05))
{
forecast = STABLE;
}
else
{
forecast = UNKNOWN;
}
// Uncomment when dubugging
// Serial.print(F("Forecast at minute "));
// Serial.print(minuteCount);
// Serial.print(F(" dP/dt = "));
// Serial.print(dP_dt);
// Serial.print(F("kPa/h --> "));
// Serial.println(weatherStrings[forecast]);
return forecast;
}Inclusion Mode ist aktiviert.
MySensors ist auf Stand V2.0 Das Gateway ist etwas älter,
Das Device 101 gab es schon ein paar Mal. Allerdings habe ich die FHEM-Config dazu bewusst nicht gespeichert sondern FHEM neu gestartet ohne Speichern.
Beim Start von FHEM meint er:
Zitat2016.07.21 12:58:07 2: Messages collected while initializing FHEM: ./log/fhem.save: Please define MYSENSOR_101 first Please define MYSENSOR_101 first Please define MYSENSOR_101 first Please define MYSENSOR_101 first Please define MYSENSOR_101 first
Wenn ich allerding den Arduino vorher getestetnen Sernsors (mit Hexenmeisters Sketch) nehme sehe ich sofort das Device 101...
ed: Also vor allem die Frage ob das Problem in FHEM oder in der Firmware zu suchen ist...
Da ich mySensors nicht dringend brauche (bis jetzt), habe ich das Gateway auch mal auf Stand V2 gebracht. Das Ergebnis war das selbe, der Sketch vom Hexenmeister funktioniert und der Sensor auf Basis mySensors 1.5 wird erkannt.
Mein (vorerst) unveränderter Sketch auf Basis V2 wird nicht erkannt.Statt dessen erhalte ich bei Verbose=5 folgende Logeinträge:
(Quelle für den Sketch:
2016.07.22 08:51:24 5: MYSENSORS/RAW: /0;255;3;0;5;0
2016.07.22 08:51:24 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL ) st=005(I_INCLUSION_MODE) ack=0 '0'
2016.07.22 08:51:24 5: MYSENSORS send: Rx: fr=000 ci=255 c=-01('' ) st=005('' ) ack=0 '1'
2016.07.22 08:51:24 5: SW: 303b3235353b2d313b303b353b310a
2016.07.22 08:51:29 5: MYSENSORS/RAW: /0;255;3;0;9;TSP:MSG:READ 101-101
2016.07.22 08:51:29 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:READ 101-101/-255 s=255,c=3,t=7,pt=0,l=0,sg=0
2016.07.22 08:51:29 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:READ 101-101-255 s=255,c=3,t=7,pt=0,l=0,sg=0/:
0;255;3;0;9;TSP:MSG:BC
0;255;3
2016.07.22 08:51:29 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'TSP:MSG:READ 101-101-255 s=255,c=3,t=7,pt=0,l=0,sg=0:'
2016.07.22 08:51:29 5: MYSENSORS gateway MySensGW: TSP:MSG:READ 101-101-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
2016.07.22 08:51:29 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'TSP:MSG:BC'
2016.07.22 08:51:29 5: MYSENSORS gateway MySensGW: TSP:MSG:BC
2016.07.22 08:51:29 5: MYSENSORS/RAW: 0;255;3/;0;9;TSP:MSG:FPAR REQ (sender=10
2016.07.22 08:51:29 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:FPAR REQ (sender=10/1)
0;255;3;0;9;TSP:CHKUPL:OK
0;2
2016.07.22 08:51:29 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'TSP:MSG:FPAR REQ (sender=101)'
2016.07.22 08:51:29 5: MYSENSORS gateway MySensGW: TSP:MSG:FPAR REQ (sender=101)
2016.07.22 08:51:29 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'TSP:CHKUPL:OK'
2016.07.22 08:51:29 5: MYSENSORS gateway MySensGW: TSP:CHKUPL:OK
2016.07.22 08:51:29 5: MYSENSORS/RAW: 0;2/55;3;0;9;TSP:MSG:GWL OK
2016.07.22 08:51:29 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'TSP:MSG:GWL OK'
2016.07.22 08:51:29 5: MYSENSORS gateway MySensGW: TSP:MSG:GWL OK
2016.07.22 08:51:29 5: MYSENSORS/RAW: /0;255;3;0;9;TSP:MSG:SEND 0-0-101
2016.07.22 08:51:29 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:SEND 0-0-101/-101 s=255,c=3,t=8,pt=1,l=1,sg=0
2016.07.22 08:51:29 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:SEND 0-0-101-101 s=255,c=3,t=8,pt=1,l=1,sg=0/,ft=0,st=ok:0
2016.07.22 08:51:29 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'TSP:MSG:SEND 0-0-101-101 s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=ok:0'
2016.07.22 08:51:29 5: MYSENSORS gateway MySensGW: TSP:MSG:SEND 0-0-101-101 s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=ok:0
2016.07.22 08:51:31 5: MYSENSORS/RAW: /0;255;3;0;9;TSP:MSG:READ 101-101
2016.07.22 08:51:31 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:READ 101-101/-0 s=255,c=3,t=24,pt=1,l=1,sg=0:
2016.07.22 08:51:31 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:READ 101-101-0 s=255,c=3,t=24,pt=1,l=1,sg=0:/1
0;255;3;0;9;TSP:MSG:PINGED (ID
2016.07.22 08:51:31 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'TSP:MSG:READ 101-101-0 s=255,c=3,t=24,pt=1,l=1,sg=0:1'
2016.07.22 08:51:31 5: MYSENSORS gateway MySensGW: TSP:MSG:READ 101-101-0 s=255,c=3,t=24,pt=1,l=1,sg=0:1
2016.07.22 08:51:31 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:PINGED (ID/=101, hops=1)
2016.07.22 08:51:31 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'TSP:MSG:PINGED (ID=101, hops=1)'
2016.07.22 08:51:31 5: MYSENSORS gateway MySensGW: TSP:MSG:PINGED (ID=101, hops=1)
2016.07.22 08:51:31 5: MYSENSORS/RAW: /0;255;3;0;9;TSP:MSG:SEND 0-0-101
2016.07.22 08:51:31 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:SEND 0-0-101/-101 s=255,c=3,t=25,pt=1,l=1,sg=
2016.07.22 08:51:31 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:SEND 0-0-101-101 s=255,c=3,t=25,pt=1,l=1,sg=/0,ft=0,st=ok:1
2016.07.22 08:51:31 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'TSP:MSG:SEND 0-0-101-101 s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=ok:1'
2016.07.22 08:51:31 5: MYSENSORS gateway MySensGW: TSP:MSG:SEND 0-0-101-101 s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=ok:1
Also habe ich nochmals genauer geforscht und herausgefunden dass mein Mustersketch nur dann funktioniert wenn alle Sensoren korrekt angeschlossen sind.
Das habe ich nun nachgeholt. Folge: Der Sensor wird von FHEM erkannt. (in meinen Augen schlechter Code, somit wird das eines der nächsten Themen sein)
Also ist meine Frage erst mal erledigt.
Ich könnte einen Tipp gebrauchen zu diesen Einträgen im FHEM Log:
Ich bin dazu zurück auf einen fertigen Stand eines Sensors:
/**
* The MySensors Arduino library handles the wireless radio link and protocol
* between your home built sensors/actuators and HA controller of choice.
* The sensors forms a self healing radio network with optional repeaters. Each
* repeater and gateway builds a routing tables in EEPROM which keeps track of the
* network topology allowing messages to be routed to nodes.
*
* Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
* Copyright (C) 2013-2015 Sensnology AB
* Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors
*
* Documentation: http://www.mysensors.org
* Support Forum: http://forum.mysensors.org
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* version 2 as published by the Free Software Foundation.
*
*******************************
*
* REVISION HISTORY
* Version 1.0 - Henrik Ekblad
*
* DESCRIPTION
* Weather station sensor example using BMP085 and DHT-11 or DHT-22 module
* http://www.mysensors.org/build/pressure
* http://www.mysensors.org/build/humidity
*
* WIRING
* DHT Sensor
* PIN2 D3 Arduino
* 10k resistor between PIN1 and PIN2
*
* BMP Sensor
* SCL A5 Arduino
* SDA A4 Arduino
*/
// Enable debug prints to serial monitor
//#define MY_DEBUG
// Enable and select radio type attached
#define MY_RADIO_NRF24
//#define MY_RADIO_RFM69
#include <SPI.h>
#include <MySensors.h>
#include <Wire.h>
#include <Adafruit_BMP085.h>
#include <DHT.h>
#include <BH1750.h>
// Set this to true if you want to send values altough the values did not change.
// This is only recommended when not running on batteries.
const bool SEND_ALWAYS = true;
// Adapt this constant: set it to the altitude above sealevel at your home location.
const float SEALEVEL = 688; // meters above sealevel
// Constant for the world wide average pressure
const float SEALEVEL_PRESSURE = 1013.25;
// ----------------------------------------------------------------------------
// Child sensor ids
#define CHILD_ID_BARO 0
#define CHILD_ID_TEMP1 1
#define CHILD_ID_HUM 2
#define CHILD_ID_TEMP2 3
// ----------------------------------------------------------------------------
// DHT-11/22
#define HUMIDITY_SENSOR_DIGITAL_PIN 3
DHT dht;
float lastTemp;
float lastHum;
boolean metric = true;
MyMessage msgHum(CHILD_ID_HUM, V_HUM);
MyMessage msgTemp(CHILD_ID_TEMP2, V_TEMP);
// ----------------------------------------------------------------------------
// BMP085
unsigned long SLEEP_TIME1 = 30000; // 1 minute required for forecast algorithm
unsigned long SLEEP_TIME2 = 30000; // 1 minute required for forecast algorithm
Adafruit_BMP085 bmp = Adafruit_BMP085(); // Digital Pressure Sensor
/*
DP/Dt explanation
0 = "Stable Weather Pattern"
1 = "Slowly rising Good Weather", "Clear/Sunny "
2 = "Slowly falling L-Pressure ", "Cloudy/Rain "
3 = "Quickly rising H-Press", "Not Stable"
4 = "Quickly falling L-Press", "Thunderstorm"
5 = "Unknown (More Time needed)
*/
const char *weatherStrings[] = { "stable", "sunny", "cloudy", "unstable", "thunderstorm", "unknown" };
enum FORECAST
{
STABLE = 0, // Stable weather
SUNNY = 1, // Slowly rising HP stable good weather
CLOUDY = 2, // Slowly falling Low Pressure System, stable rainy weather
UNSTABLE = 3, // Quickly rising HP, not stable weather
THUNDERSTORM = 4, // Quickly falling LP, Thunderstorm, not stable
UNKNOWN = 5 // Unknown, more time needed
};
const char *situationStrings[] = { "very low", "low", "normal", "high", "very high" };
enum WEATHER_SITUATION
{
VERY_LOW_PRESSURE = 0, // p > -7.5hPa
LOW_PRESSURE = 1, // p > -2.5hPa
NORMAL_PRESSURE = 2, // p < +/-2.5hPa
HIGH_PRESSURE = 3, // p > +2.5hPa
VERY_HIGH_PRESSURE = 4, // p > +7.5hPa
};
float lastPressure = -1;
float lastPressureTemp = -1;
int lastForecast = -1;
int lastSituation = NORMAL_PRESSURE;
const int LAST_SAMPLES_COUNT = 5;
float lastPressureSamples[LAST_SAMPLES_COUNT];
// get kPa/h be dividing hPa by 10
#define CONVERSION_FACTOR (1.0/10.0)
int minuteCount = 0;
bool firstRound = true;
// average value is used in forecast algorithm.
float pressureAvg;
// average after 2 hours is used as reference value for the next iteration.
float pressureAvg2;
float dP_dt;
MyMessage tempMsg(CHILD_ID_TEMP1, V_TEMP);
MyMessage pressureMsg(CHILD_ID_BARO, V_PRESSURE);
MyMessage forecastMsg(CHILD_ID_BARO, V_FORECAST);
MyMessage situationMsg(CHILD_ID_BARO, V_VAR1);
MyMessage forecastMsg2(CHILD_ID_BARO, V_VAR2);
void initPressureSensor()
{
if (!bmp.begin())
{
Serial.println(F("Could not find a valid BMP085 sensor, check wiring!"));
while (1) {}
}
}
void initHumiditySensor()
{
dht.setup(HUMIDITY_SENSOR_DIGITAL_PIN);
}
void setup()
{
initPressureSensor();
initHumiditySensor();
metric = getConfig().isMetric;
}
void presentation()
{
sendSketchInfo("Weather Station Sensor", "1.0");
present(CHILD_ID_BARO, S_BARO);
present(CHILD_ID_TEMP1, S_TEMP);
present(CHILD_ID_HUM, S_HUM);
present(CHILD_ID_TEMP2, S_TEMP);
}
int getWeatherSituation(float pressure)
{
int situation = NORMAL_PRESSURE;
float delta = pressure - SEALEVEL_PRESSURE;
if (delta > 7.5)
{
situation = VERY_HIGH_PRESSURE;
}
else if (delta > 2.5)
{
situation = HIGH_PRESSURE;
}
else if (delta < -7.5)
{
situation = VERY_LOW_PRESSURE;
}
else if (delta < -2.5)
{
situation = LOW_PRESSURE;
}
else
{
situation = NORMAL_PRESSURE;
}
return situation;
}
// The BMP provides a temperature value, too!
bool updatePressureSensor()
{
bool changed = false;
//sealevel pressure p0 from absolute pressure.
float pressure = bmp.readSealevelPressure(SEALEVEL) / 100.0;
float temperature = bmp.readTemperature();
if (!metric)
{
// Convert to fahrenheit
temperature = temperature * 9.0 / 5.0 + 32.0;
}
int forecast = sample(pressure);
int situation = getWeatherSituation(pressure);
if (SEND_ALWAYS || (temperature != lastPressureTemp))
{
changed = true;
lastPressureTemp = temperature;
#ifdef MY_DEBUG
Serial.print(F("Temperature = "));
Serial.print(temperature);
Serial.println(metric ? F(" *C") : F(" *F"));
#endif
if (!send(tempMsg.set(lastPressureTemp, 1)))
{
lastPressureTemp = -1.0;
}
}
if (SEND_ALWAYS || (pressure != lastPressure))
{
changed = true;
lastPressure = pressure;
#ifdef MY_DEBUG
Serial.print(F("sealevel Pressure = "));
Serial.print(pressure);
Serial.println(F(" hPa"));
#endif
if (!send(pressureMsg.set(lastPressure, 1)))
{
lastPressure = -1.0;
}
}
if (SEND_ALWAYS || (forecast != lastForecast))
{
changed = true;
lastForecast = forecast;
#ifdef MY_DEBUG
Serial.print(F("Forecast = "));
Serial.println(weatherStrings[forecast]);
#endif
if (send(forecastMsg.set(weatherStrings[lastForecast])))
{
if (!send(forecastMsg2.set(lastForecast)))
{
}
}
else
{
lastForecast = -1.0;
}
}
if (SEND_ALWAYS || (situation != lastSituation))
{
changed = true;
lastSituation = situation;
#ifdef MY_DEBUG
Serial.print(F("Situation = "));
Serial.println(situationStrings[situation]);
#endif
if (!send(situationMsg.set(lastSituation, 0)))
{
lastSituation = -1.0;
}
}
return changed;
}
// The dht provides a temperature, too!
bool updateHumiditySensor()
{
bool changed = false;
float temperature = dht.getTemperature();
float humidity = dht.getHumidity();
if (!isnan(temperature))
{
if (SEND_ALWAYS || (temperature != lastTemp))
{
lastTemp = temperature;
if (!metric)
{
temperature = dht.toFahrenheit(temperature);
}
changed = true;
#ifdef MY_DEBUG
Serial.print(F("T: "));
Serial.println(temperature);
#endif
if (!send(msgTemp.set(temperature, 1)))
{
lastTemp = -1.0;
}
}
}
else
{
Serial.println(F("Failed reading temperature from DHT"));
}
if (!isnan(humidity))
{
if (SEND_ALWAYS || (humidity != lastHum))
{
lastHum = humidity;
changed = true;
#ifdef MY_DEBUG
Serial.print(F("H: "));
Serial.println(humidity);
#endif
if (!send(msgHum.set(lastHum, 1)))
{
lastHum = -1.0;
}
}
}
else
{
Serial.println(F("Failed reading humidity from DHT"));
}
return changed;
}
void loop()
{
updatePressureSensor();
sleep(SLEEP_TIME1);
updateHumiditySensor();
sleep(SLEEP_TIME2);
}
float getLastPressureSamplesAverage()
{
float lastPressureSamplesAverage = 0;
for (int i = 0; i < LAST_SAMPLES_COUNT; i++)
{
lastPressureSamplesAverage += lastPressureSamples[i];
}
lastPressureSamplesAverage /= LAST_SAMPLES_COUNT;
// Uncomment when dubugging
//Serial.print(F("### 5min-Average:"));
//Serial.print(lastPressureSamplesAverage);
//Serial.println(F(" hPa"));
return lastPressureSamplesAverage;
}
// Algorithm found here
// http://www.freescale.com/files/sensors/doc/app_note/AN3914.pdf
// Pressure in hPa --> forecast done by calculating kPa/h
int sample(float pressure)
{
// Calculate the average of the last n minutes.
int index = minuteCount % LAST_SAMPLES_COUNT;
lastPressureSamples[index] = pressure;
minuteCount++;
if (minuteCount > 185)
{
minuteCount = 6;
}
if (minuteCount == 5)
{
pressureAvg = getLastPressureSamplesAverage();
}
else if (minuteCount == 35)
{
float lastPressureAvg = getLastPressureSamplesAverage();
float change = (lastPressureAvg - pressureAvg) * CONVERSION_FACTOR;
if (firstRound) // first time initial 3 hour
{
dP_dt = change * 2; // note this is for t = 0.5hour
}
else
{
dP_dt = change / 1.5; // divide by 1.5 as this is the difference in time from 0 value.
}
}
else if (minuteCount == 65)
{
float lastPressureAvg = getLastPressureSamplesAverage();
float change = (lastPressureAvg - pressureAvg) * CONVERSION_FACTOR;
if (firstRound) //first time initial 3 hour
{
dP_dt = change; //note this is for t = 1 hour
}
else
{
dP_dt = change / 2; //divide by 2 as this is the difference in time from 0 value
}
}
else if (minuteCount == 95)
{
float lastPressureAvg = getLastPressureSamplesAverage();
float change = (lastPressureAvg - pressureAvg) * CONVERSION_FACTOR;
if (firstRound) // first time initial 3 hour
{
dP_dt = change / 1.5; // note this is for t = 1.5 hour
}
else
{
dP_dt = change / 2.5; // divide by 2.5 as this is the difference in time from 0 value
}
}
else if (minuteCount == 125)
{
float lastPressureAvg = getLastPressureSamplesAverage();
pressureAvg2 = lastPressureAvg; // store for later use.
float change = (lastPressureAvg - pressureAvg) * CONVERSION_FACTOR;
if (firstRound) // first time initial 3 hour
{
dP_dt = change / 2; // note this is for t = 2 hour
}
else
{
dP_dt = change / 3; // divide by 3 as this is the difference in time from 0 value
}
}
else if (minuteCount == 155)
{
float lastPressureAvg = getLastPressureSamplesAverage();
float change = (lastPressureAvg - pressureAvg) * CONVERSION_FACTOR;
if (firstRound) // first time initial 3 hour
{
dP_dt = change / 2.5; // note this is for t = 2.5 hour
}
else
{
dP_dt = change / 3.5; // divide by 3.5 as this is the difference in time from 0 value
}
}
else if (minuteCount == 185)
{
float lastPressureAvg = getLastPressureSamplesAverage();
float change = (lastPressureAvg - pressureAvg) * CONVERSION_FACTOR;
if (firstRound) // first time initial 3 hour
{
dP_dt = change / 3; // note this is for t = 3 hour
}
else
{
dP_dt = change / 4; // divide by 4 as this is the difference in time from 0 value
}
pressureAvg = pressureAvg2; // Equating the pressure at 0 to the pressure at 2 hour after 3 hours have past.
firstRound = false; // flag to let you know that this is on the past 3 hour mark. Initialized to 0 outside main loop.
}
int forecast = UNKNOWN;
if (minuteCount < 35 && firstRound) //if time is less than 35 min on the first 3 hour interval.
{
forecast = UNKNOWN;
}
else if (dP_dt < (-0.25))
{
forecast = THUNDERSTORM;
}
else if (dP_dt > 0.25)
{
forecast = UNSTABLE;
}
else if ((dP_dt > (-0.25)) && (dP_dt < (-0.05)))
{
forecast = CLOUDY;
}
else if ((dP_dt > 0.05) && (dP_dt < 0.25))
{
forecast = SUNNY;
}
else if ((dP_dt >(-0.05)) && (dP_dt < 0.05))
{
forecast = STABLE;
}
else
{
forecast = UNKNOWN;
}
// Uncomment when dubugging
// Serial.print(F("Forecast at minute "));
// Serial.print(minuteCount);
// Serial.print(F(" dP/dt = "));
// Serial.print(dP_dt);
// Serial.print(F("kPa/h --> "));
// Serial.println(weatherStrings[forecast]);
return forecast;
}
Inclusion Mode ist aktiviert.
MySensors ist auf Stand V2.0 Das Gateway ist etwas älter,
Das Device 101 gab es schon ein paar Mal. Allerdings habe ich die FHEM-Config dazu bewusst nicht gespeichert sondern FHEM neu gestartet ohne Speichern.
Beim Start von FHEM meint er:
Wenn ich allerding den Arduino vorher getestetnen Sernsors (mit Hexenmeisters Sketch) nehme sehe ich sofort das Device 101...
ed: Also vor allem die Frage ob das Problem in FHEM oder in der Firmware zu suchen ist...
[/quote]
Hallo zusammen,
ich habe nun auch versucht bei mir MySensors zum laufen zu bringen.
Dabei habe ich einen RPi an dem das NRF Funkmodul hängt und auch per FHEM angesprochen werden kann. Gateway hat den Status "opened" und die Version 1.4, installiert habe ich es am RPi hier nach:
https://github.com/mysensors/Raspberry
Dazu habe ich einen Sensebender Micro Sensor zum testen. Dort habe ich bisher nur den Beispiel Sketch drauf gespielt (https://www.mysensors.org/hardware/micro#example-sketch) und monitore ihn über die Arduino Software.
Autocreate ist sowohl in FHEM als auch für den Gateway aktiviert, nur das Device wird nicht angelegt. Ich bekomme im Log nur die Meldungen
016.09.25 16:11:17 3: MYSENSORS: ignoring internal-msg from unknown radioId 100, childId 255 for
2016.09.25 16:11:27 3: MYSENSORS: ignoring internal-msg from unknown radioId 100, childId 255 for
2016.09.25 16:11:33 3: MYSENSORS: ignoring internal-msg from unknown radioId 100, childId 255 for
2016.09.25 16:11:42 3: MYSENSORS: ignoring internal-msg from unknown radioId 100, childId 255 for
2016.09.25 16:11:49 3: MYSENSORS: ignoring internal-msg from unknown radioId 100, childId 255 for
2016.09.25 16:11:58 3: MYSENSORS: ignoring internal-msg from unknown radioId 100, childId 255 for
2016.09.25 16:12:06 3: MYSENSORS: ignoring internal-msg from unknown radioId 100, childId 255 for
2016.09.25 16:12:14 3: MYSENSORS: ignoring internal-msg from unknown radioId 100, childId 255 for
2016.09.25 16:12:22 3: MYSENSORS: ignoring internal-msg from unknown radioId 100, childId 255 for
2016.09.25 16:12:32 3: MYSENSORS: ignoring internal-msg from unknown radioId 100, childId 255 for
Ich habe den Sensor schon mehrfach neu angesteckt, position verändert, Eeprom gelöscht, aber komme einfach nicht weiter.
Könnt ihr mir hier helfen?
Danke und viele Grüße
Gizmoh
Zitat von: Gizmoh am 25 September 2016, 16:13:58
Hallo zusammen,
ich habe nun auch versucht bei mir MySensors zum laufen zu bringen.
Dabei habe ich einen RPi an dem das NRF Funkmodul hängt und auch per FHEM angesprochen werden kann. Gateway hat den Status "opened" und die Version 1.4, installiert habe ich es am RPi hier nach:
https://github.com/mysensors/Raspberry
Dazu habe ich einen Sensebender Micro Sensor zum testen. Dort habe ich bisher nur den Beispiel Sketch drauf gespielt (https://www.mysensors.org/hardware/micro#example-sketch) und monitore ihn über die Arduino Software.
Autocreate ist sowohl in FHEM als auch für den Gateway aktiviert, nur das Device wird nicht angelegt. Ich bekomme im Log nur die Meldungen
016.09.25 16:11:17 3: MYSENSORS: ignoring internal-msg from unknown radioId 100, childId 255 for
2016.09.25 16:11:27 3: MYSENSORS: ignoring internal-msg from unknown radioId 100, childId 255 for
2016.09.25 16:11:33 3: MYSENSORS: ignoring internal-msg from unknown radioId 100, childId 255 for
2016.09.25 16:11:42 3: MYSENSORS: ignoring internal-msg from unknown radioId 100, childId 255 for
2016.09.25 16:11:49 3: MYSENSORS: ignoring internal-msg from unknown radioId 100, childId 255 for
2016.09.25 16:11:58 3: MYSENSORS: ignoring internal-msg from unknown radioId 100, childId 255 for
2016.09.25 16:12:06 3: MYSENSORS: ignoring internal-msg from unknown radioId 100, childId 255 for
2016.09.25 16:12:14 3: MYSENSORS: ignoring internal-msg from unknown radioId 100, childId 255 for
2016.09.25 16:12:22 3: MYSENSORS: ignoring internal-msg from unknown radioId 100, childId 255 for
2016.09.25 16:12:32 3: MYSENSORS: ignoring internal-msg from unknown radioId 100, childId 255 for
Ich habe den Sensor schon mehrfach neu angesteckt, position verändert, Eeprom gelöscht, aber komme einfach nicht weiter.
Könnt ihr mir hier helfen?
Danke und viele Grüße
Gizmoh
Das Problem liegt nicht am Sensor, dein Gateway kennt den Sensor nicht. Hast du den inclusion mode aktiviert?
Sent from my iPad using Tapatalk
Jepp, hatte ich aktiviert. Der Fehler war scheinbar, dass ich unterschiedliche MySensors Versionen eingesetzt hatte, der Gateway lief auf der 1.4 Version, der Sensor auf der 2.0. Habe jetzt beides auf der 1.4 und jetzt geht es.
Nur bekomme ich keine Luftfeuchtigkeit-Messungen angezeigt. Im Sketch vom Sensor habe ich
gw.send(msgTemp.set(temperature,1));
gw.send(msgHum.set(humidity));
in FHEM wurde korrekt angelegt
mapReading_temperature1 1 temperature
aber kein Reading für humidity. Was muss ich hier tun um das noch zu bekommen?
Zitat von: Gizmoh am 26 September 2016, 09:20:29
Jepp, hatte ich aktiviert. Der Fehler war scheinbar, dass ich unterschiedliche MySensors Versionen eingesetzt hatte, der Gateway lief auf der 1.4 Version, der Sensor auf der 2.0. Habe jetzt beides auf der 1.4 und jetzt geht es.
Hallo Gizmoh,
das RPi-Gateway scheint noch sehr "beta" zu sein, dafür ist der Rest der libs, die Du dann verwendest nicht mehr Stand der Dinge. Wenn Du kein Experte bist, düfte es sinnvoller sein, erst mal mit einem anderen GW zu starten und dafür die aktuellen Mysensors-libs zu nehmen. Als "nur" GW ist der PI überdimensioniert und wenn Du auch FHEM darauf laufen hast, beschränkten sich die zusätzlichen Aufwendungen auf einen Arduino für ein serielles GW (oder einen ESP8266 für ein WIFI-GW).
Gruß
Beta-User
Hallo, habe seit kurzem mein USB Gateway auf Wifi umgestellt und vorerst läuft alles.
Nur ein Sensor mit einem SI7021 liefert jetzt bei der Luftfeuchte komische Werte wie z.Bsp. einen Wert von "1090519092".
Weiß jemand woran das liegen könnte?
Zitat von: devil77 am 05 Oktober 2016, 09:56:58
Hallo, habe seit kurzem mein USB Gateway auf Wifi umgestellt und vorerst läuft alles.
Nur ein Sensor mit einem SI7021 liefert jetzt bei der Luftfeuchte komische Werte wie z.Bsp. einen Wert von "1090519092".
Weiß jemand woran das liegen könnte?
Welche Version der MySensors-Lib und der ESP-libs nutzt Du? Bei "älteren" Versionen gab es immer mal wieder diese Art von Problemen bei den WIFI-GW's, die sollten MySensors 2.0.x sein...
Mysensor lib bei beiden 1.5.4 und ESP-lib 2.3
Zitat von: devil77 am 05 Oktober 2016, 10:33:31
Mysensor lib bei beiden 1.5.4 und ESP-lib 2.3
Dann dürfte es derselbe Effekt wie hier sein: https://forum.fhem.de/index.php/topic,49790.0.html
=> update (GW reicht) auf 2.0.x...
Danke, werde ich mal versuchen.
Hallo,
ich hab mich heute mal an MySensors gemacht, mit dem Ziel, mein Display von LAN auf Funk umzustellen.
Die Kommunikation scheint auch prinzipiell zu klappen, aber wenn ich das jetzt richtig sehe, habe ich direkt den Fehler gemacht, Messagetypen aus der V2.0 zu verwenden, die FHEM noch nicht unterstützt.
Kann es sein, dass S_INFO in FHEM noch nicht funktioniert? Gibts dafür schon Lösungen, oder bin ich der einzige, der das bräuchte?
*edit*
Okay, kaum hat man sich ausgeweint, gehts aufwärts.
Ich hab mir von hier (https://forum.mysensors.org/topic/540/fhem/18) die modifzierten Dateien geladen. ( Falls du hier mitliest: Vielen Dank! )
An der MYSENSORS_DEVICE hatte ich schon selber gebastelt, aber nicht realisert, dass die Constants.pm mitspielt.
Jetzt funktionierts, aber ein paar Dinge sind noch seltsam:
Mein Node-Sketch bietet 3 Funktionen ( ich glaube "Sensoren" oder "Childs" in MySensors-Sprachgebrauch? ) an:
ID 10: S_INFO (Text 1)
ID 11: S_INFO (Text 2)
ID 12: S_BINARY ( An/Aus )
Laut Serial-Monitor bietet er auch die an:
s=10,c=0,t=36
s=11,c=0,t=36
s=12,c=0,t=3
zustätzlich noch dreinmal s=255 mit Name, Version und wofür das dritte ist, weiß ich nicht.
In FHEM habe ich aber seltsamerweise für die Sensoren/Childs (?) 10 und 11 jeweils ein Reading armed, level und tripped, dabei sollte es nach meinem ( zugegebenermaßen bisher bescheidenen ) Verständnis nur eins mit text geben. Das habe ich mir jetzt mit mapReading und setReading selbst angelegt und darüber funktioniert soweit auch alles, aber dennoch wundern mich die übrigen Readings.
S_INFO ist derzeit leider tatsächlich noch nicht eingebaut. Ich habe dies am Freitag mal schnell probiert, aber noch nicht testen können:
https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/lib/Device/MySensors/Constants.pm
https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/00_MYSENSORS.pm
https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/10_MYSENSORS_DEVICE.pm
(auf eigene Gefahr zum Testen :))
Zitat von: Hauswart am 10 Oktober 2016, 10:20:21
S_INFO ist derzeit leider tatsächlich noch nicht eingebaut. Ich habe dies am Freitag mal schnell probiert, aber noch nicht testen können:
https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/lib/Device/MySensors/Constants.pm
https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/00_MYSENSORS.pm
https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/10_MYSENSORS_DEVICE.pm
(auf eigene Gefahr zum Testen :))
Hmm... Wie gesagt, prinzipiell funktionierts bei mir jetzt. Erscheint mur nur seltsam. Ich hab bisher nur den einen ( logischerweise selbstgebauten ) "Sensor", daher fehlt mir die Vergleichsmöglichkeit, was normales Verhalten ist.
Die Änderungen in den von dir verlinkten Modulen sind auf jeden Fall etwas anders, als die, die ich jetzt probiert habe. Werde mal testen.
Was mich allerdings wundert: In den static_types ist "receives" und "sends" doch aus Sicht des Sensors gesehen, oder? Also alle Werttypen, die der Sensor sendet in "sends" und alle, die er empfängt in "receives"? Dann müsste V_Text bei S_Info doch in receives und nicht in sends, oder? Der Text wird doch vom Display empfangen. Bei der Version die ich jetzt verwende, steht V_Text in sends und receives.
Hallo Carsten,
du hast Recht, ich habe es angepasst. Texte machen wohl Sinn auch von FHEM => MySensors zu senden.
Gruss
Edit: Was ich noch testen muss S_LIGHT habe ich komplett entfernt, da es nicht mehr verwendet werden soll, ob ich einen Parallelbetrieb zur Verfügung stellen kann.
Achso, der Fork ist von dir? Das war mir gar nicht klar. Umso besser!
Ich werd die Tage mal testen.
Zitat von: Carsten am 10 Oktober 2016, 11:00:29
Achso, der Fork ist von dir? Das war mir gar nicht klar. Umso besser!
Ich werd die Tage mal testen.
Die Links bzw. der Fork oben ja :) Die ursprüngliche MySensors Integration ist aber von Norbert: https://github.com/ntruchsess/fhem-mirror
Wie wäre es mit einem Pull-Request an Norbert, um die Änderungen zu integrieren?
Zitat von: hexenmeister am 10 Oktober 2016, 12:36:19
Wie wäre es mit einem Pull-Request an Norbert, um die Änderungen zu integrieren?
Erfolgt, sobald die Änderungen getestet sind :)
Hallo,
hab deine Version jetzt getestet und S_INFO funktioniert jetzt wie erwartet mit meinem bisher einzigen Sensor ( V2, 2 x S_INFO 1x S_BINARY ). Danke für die Anpassung!
S_BINARY funktioniert auch, legt aber verwirrenderweise auch ein Reading_Power an. Das ist aber wohl auch im Sinne der API, da Binary wohl V_STATUS und V_WATT als Variablen enthält.
Halte ich persönlich für einen Designfehler seitens MySensors dem Boolean als eigentlich einfachst möglichen Werttypen einen zusätzlichen Float zu verpassen, ist aber wohl historisch gewachsen. FHEM macht hier imho alles korrekt.
Was FHEM meiner Meinung nach falsch macht, ist die Antwort auf einen Timerequest als UTC zu schicken. Laut diesem Thread im MySensors-Forum (https://forum.mysensors.org/topic/1835/adjust-time/17) sollte das die Localtime sein. Halte ich persönlich auch für sinnvoller, als die Timezone im Sensor umzurechnen. Domoticz schickt z.B. mittlerweile auch die Localtime, wodurch der gleiche Sensor in FHEM und Domoticz jetzt andere Zeiten anzeigen würde. Ich fände hier aus Kompatibilitätsgründen einen Schalter ( im Sinne von Attribut ) in FHEM gut, um einzustellen, ob UTC oder Localtime als I_TIME verwendet werden soll
UTC war bis 1.5.x Standard. Da hatte ich mich auch schon mal gewundert...
Zitat
mysensors API (1.5)
I_TIME 1 Sensors can request the current time from the Controller using this message. The time will be reported as the seconds since 1970
Wichtig wäre, dass auch weiterhin UTC gesendet werden kann, um abwärtskompatibel zu sein.
Zitat von: KarlHeinz2000 am 13 Oktober 2016, 16:12:57
UTC war bis 1.5.x Standard. Da hatte ich mich auch schon mal gewundert...
Da steht aber doch prinzipiell nichts von UTC. Hier ( in GMT +2 ) ist 1970 halt schon 7200 länger her. ;D
Zitat von: KarlHeinz2000 am 13 Oktober 2016, 16:12:57
Wichtig wäre, dass auch weiterhin UTC gesendet werden kann, um abwärtskompatibel zu sein.
Sehe ich ein. Deswegen fände ich ja ein Attribut zum Umschalten gut.
Gibts eigentlich gar keine Funktion in Perl, die das einfach umrechnet? Ich dachte, das würde localtime( ) machen, aber localtime gibt scheinbar ein Array zurück, statt Sekunden seit X.
Hat noch jemand das Problem, dass ein Node als Repeater mit ID auftaucht? Ist das normal?
Habe das Problem erst seit der neuen beta...
Der Repeater (State: OK) der auftaucht wenn man ein Gateway definiert scheint ja auch normal zu sein.
anscheinend hat sich da irgendwie ein Fehler eingeschlichen:
In der Datei 10_MYSENSORS_DEVICE.pm fehlt ein ganzer FunktionsBlock wenn ich das richtig sehe:
Fehler beim anlegen von neuen Devices mit "Inclusion Mode" im Log und FHEM crasht.
Undefined subroutine &MYSENSORS::DEVICE::sendMessage called at ./FHEM/10_MYSENSORS_DEVICE.pm line 574
FHEM ist Aktuell
Zitat von: kleinerDrache am 26 Oktober 2016, 16:57:19
anscheinend hat sich da irgendwie ein Fehler eingeschlichen:
In der Datei 10_MYSENSORS_DEVICE.pm fehlt ein ganzer FunktionsBlock wenn ich das richtig sehe:
Fehler beim anlegen von neuen Devices mit "Inclusion Mode" im Log und FHEM crasht.
Undefined subroutine &MYSENSORS::DEVICE::sendMessage called at ./FHEM/10_MYSENSORS_DEVICE.pm line 574
FHEM ist Aktuell
Verwendest du die die aktuelle stable Version? Oder von meine Development-Version?
Zitat von: kleinerDrache am 26 Oktober 2016, 16:57:19
Undefined subroutine &MYSENSORS::DEVICE::sendMessage called at ./FHEM/10_MYSENSORS_DEVICE.pm line 574
M.E. gehört diese Subroutine zu 00_MYSENSORS.pm. Ist diese vorhanden und auf dem letzten Stand (2015-10-02 ntruchses)?
Zitat von: Hauswart am 27 Oktober 2016, 08:27:23
Verwendest du die die aktuelle stable Version? Oder von meine Development-Version?
Hauswart,
ohne jetzt einen Blick auf den Code geworfen zu haben: Hast Du alle drei .pm (00_MYSENSORS.pm, 10_MYSENSORS_DEVICE.pm und die neue Constants.pm) neu zusammengebastelt? Dann könnte der von mir an andere Stelle gepostete Fehler damit zusammenhängen, dass ich (wie dort angegeben) nur die beiden letzten in mein /FHEM-Verzeichnis kopiert hatte...
Gruß,
Beta-User
Zitat von: Beta-User am 27 Oktober 2016, 08:48:27
ohne jetzt einen Blick auf den Code geworfen zu haben: Hast Du alle drei .pm (00_MYSENSORS.pm, 10_MYSENSORS_DEVICE.pm und die neue Constants.pm) neu zusammengebastelt? Dann könnte der von mir an andere Stelle gepostete Fehler damit zusammenhängen, dass ich (wie dort angegeben) nur die beiden letzten in mein /FHEM-Verzeichnis kopiert hatte...
Ja, ich hatte alle drei bearbeitet. :)
Zitat von: Hauswart am 10 Oktober 2016, 10:20:21
[...]
https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/lib/Device/MySensors/Constants.pm (https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/lib/Device/MySensors/Constants.pm)
https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/00_MYSENSORS.pm (https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/00_MYSENSORS.pm)
https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/10_MYSENSORS_DEVICE.pm (https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/10_MYSENSORS_DEVICE.pm)
[...]
Gruss
Zitat von: Hauswart am 27 Oktober 2016, 10:53:39
Ja, ich hatte alle drei bearbeitet. :)
Gruss
Danke für die Info, dann teste ich es ggf. doch nochmal. Die Frage resultierte aus einem anderen Thread, und da war nur von 2 .pm die Rede ;):
Zitat von: Hauswart am 07 Oktober 2016, 09:35:12
Möchtest du mal folgende Dateien testen? ...
Btw.: Mit welcher/welchen Mysensors-Versionen arbeitest Du gerade? Bei mir funktioniert das Mischen von "vor-2.0.1"-Nodes mit einem aktuellen seriellen GW nicht :'(.
Hatte alle drei Dateien rein kopiert und hat auch bestens funktioniert. Nach dem letzten update kam es dann zu dem Fehler. Und sorry hab auch schon gesehen das die Send Funktion aus der der Mysensors.pm kommt bin nicht so ganz firm in perl. Verwende hier durchgehend mysensors 2.0.0 und zusätzlich noch Mycontroller für Firmware und co.
Zitat von: kleinerDrache am 27 Oktober 2016, 11:59:14
Hatte alle drei Dateien rein kopiert und hat auch bestens funktioniert. Nach dem letzten update kam es dann zu dem Fehler.
Du hast meine Dateien ausprobiert und dies ging ohne Probleme. Und nach dem letzten FHEM-Update kamen die Probleme? Versuche mal meine Dateien neu herunterzuladen, nicht das FHEM die teilweise überschrieben hat.
Hab die Dateien gerade neu reinkopiert und FHEM neugestartet. Inclusion Mode auf 1 gesetzt ,Node eingeschaltet etwas gewartet und FHEM crasht .
Log Meldungen :
2016.10.27 12:15:25 3: MYSENSORS: ignoring set-msg from unknown radioId 0, childId 0 for V_TEMP
2016.10.27 12:15:25 3: MYSENSORS: ignoring set-msg from unknown radioId 0, childId 1 for V_PRESSURE
2016.10.27 12:15:25 3: MYSENSORS: ignoring set-msg from unknown radioId 0, childId 1 for V_FORECAST
Undefined subroutine &MYSENSORS::DEVICE::sendMessage called at ./FHEM/10_MYSENSORS_DEVICE.pm line 574.
ok hat sich anscheinend erledigt.
Hab nochmal alles was mit MySensors zu tun hat aus FHEM entfernt. Diesmal mit eventTypes löschen (flush und clear) dann kann ich alles neu einrichten und Inclusion Funktioniert wieder.
Irgendwo iss zwar ein Wurm drinn ;) aber hier für mich funktioniert es wieder.
nochmal zum system:
Cubietruck mit Armbian (aktueller Stand)
FHEM (aktueller Stand)
ConfigDB und LogDB
MySensors 2.0.0
Denke wenn liegt es an der ConfigDB oder den eventTypes????? (LogDB bekommt keine Werte von MySensors)
Hallo zusammen,
sorry, dass ich vermutlich Euren Thread durcheinanderbringe, aber ich (als MySensors newbie) habe folgendes Problem:
- serielles Gateway mit dem MySensors orignal Sketch geflasht
- wenn ich einen Sensor auf dem Arduino pro mini mit DS1820 dranhänge funktioniert das Ganze
- ich habe mir zwei SensebenderMicros zugelegt
* da schon das EEPROM mal vorsichtshalber gelöscht
* den Sensebender Micro Sketch geflasht und MY_DEBUG angeschaltet
Debug Meldungen:
Starting sensor (RNONA-, 2.0.0)
TSM:INIT
TSM:RADIO:OK
TSM:FPAR
TSP:MSG:SEND 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSM:FPAR:FAIL
!TSM:FAILURE
TSM:PDT
fhem.log:
2016.10.23 13:32:54 3: MYSENSORS: ignoring internal-msg from unknown radioId 195, childId 255 for
2016.10.23 13:33:00 3: MYSENSORS: ignoring internal-msg from unknown radioId 195, childId 255 for
2016.10.23 13:33:06 3: MYSENSORS: ignoring internal-msg from unknown radioId 195, childId 255 for
Muss ich irgendwo die RadioID einstellen? Ich dachte, das geht irgendwie automatisch ...
Ich wäre echt dankbar, wenn ich einen kleinen Schubs in die richtige Richtung bekommen würde.
Danke + Gruß
Peter
Da ich am Anfang bei meinen Tests manchmal etwas durcheinander gekommen bin (und damals die Logik der ID-Vergabe - zumindest bei mir - nicht immer so richtig funktioniert habt), habe ich mir angewöhnt, die IDs immer fest zu vergeben.
// If you're using static ids for your sensor, add:
#define MY_NODE_ID 102
Gruß
Holger
Zitat von: Omega am 27 Oktober 2016, 21:20:38
Da ich am Anfang bei meinen Tests manchmal etwas durcheinander gekommen bin (und damals die Logik der ID-Vergabe - zumindest bei mir - nicht immer so richtig funktioniert habt), habe ich mir angewöhnt, die IDs immer fest zu vergeben.
// If you're using static ids for your sensor, add:
#define MY_NODE_ID 102
Danke für die Info. Sehe ich die ID des Gateways in fhem, oder muss ich den Sketch neu compilieren/flashen?
Danke + Gruß
Peter
Gateway hat keine ID. Nur der Sensor. Den Sketch musst du dazu neu kompilieren und flashen.
Aus meinen Aufzeichnungen habe ich dazu folgendes gefunden (das war noch ohne fest vergebene ID):
define MySensorsGateway MYSENSORS 192.168.0.128:5003
attr MySensorsGateway room MySensors
attr MySensorsGateway autocreate 1
set MySensorsGateway inclusion-mode on
# unter Everything ist MYSENSOR_100 zu sehen
attr MYSENSOR_100 room MySensors
Und dann den Sensor entsprechend weiterbearbeiten (Attribute).
@Hauswart
Du übernimmst ja gerade die löbliche Aufgabe zur Anpassung an die aktuelle Lib :).
Dazu hätte ich gerne noch folgenden Wunsch (wenn ohne zu großen Aufwand umsetzbar): mich stört immer wieder mal, dass ich nicht wirklich sehen kann, ob das Gateway noch ,,lebt". Momentan behelfe ich mir damit, die Sensoren nach (ausbleibenden) Meldungen abzufragen. Lieber wäre mir aber ein Reading im Gateway, dass regelmäßig aktualisiert wird (Timestamp) und damit dann auch geprüft werden könnte.
LG
Holger
Aktivier im Gateway bei FHEM mal die Funktion Autocreate (sonst werden Nodes nur 30 Sekunden lang nach entweder "Inclusion-Button drücken" oder "Inclusion On" Im Gatewaydevice gesucht) und das auch nur wenn das Node gerade erst eingeschaltet oder resetet wird. AutoID funktioniert ID's fangen dann mit 100 an und werden automatisch hochgezählt.
Edit: ok gerade festgestellt das auch bei autocreate 1 die sensoren nur nach einem reset erkannt werden aber das button drücken und losrennen die zu reseten innerhalb von 30 sek. fällt weg ;)
Hm, bei fixer Node ID kommt trotzdem folgende Fehlermeldung:
2016.10.27 22:02:20 3: MYSENSORS: ignoring internal-msg from unknown radioId 81, childId 255 for
2016.10.27 22:02:26 3: MYSENSORS: ignoring internal-msg from unknown radioId 81, childId 255 for
Ich meine, der Sketch auf dem Gateway ist mit der Library 1.5.4 kompiliert, der auf dem Sensebender Micro mit Library 2.0.0. Hat das einen Einfluss?
Danke + Gruß
PeMue
Die Version des Gateways muss immer höher sein als die des Sensors. Ich habe hier ein Gateway mit 2.0 Version laufen und Sensoren sowohl mit 1.5.4 und 2.0, selbst Mischbetrieb bei den Sensoren ist möglich.
Update mal das Gateway auch auf die 2.0 Version. Dann sollte es klappen.
Oder du spielst auf den Sensoren auch die 1.5.4 auf. Dann klappt es auch wieder.
Die Fehlermeldung sagt nur das das MySensors Modul deine Node nicht kennt. Hab ich auch wenn ich eine neue Node ohne Autocreate oder Inclusion Mode einschalte. Ist nur die Meldung "ok da iss was aber ich kenns nicht" wie Die Meldungen von HM oder Lacrosse wenn Sensoren senden Die nicht gepairt sind.
Edit: ok nicht schlagen gloob hat recht zumindest gleichhoch muss der Gateway sein wie die Version auf dem Node.
Sorry bin nur am Handy. Genau das Gateway sollte immer möglichst aktuell sein. Bei dir sieht es wirklich so aus, als ob der Node nicht gepairt wurde. In FHEM das Gateway in den Pairing Modus setzen und den Sensor dann resetten oder kurz Strom los machen.
Genau oder halt Autocreate einschalten und dann resetten oder kurz strom wech.
Das hinter "for" in der Fehlermeldung nix mehr steht kommt wohl vom Gateway weil der mit der alten lib kompiliert wurde sonnst müsste da was von V_......... stehen wies im Sketch angegeben ist.
Zitat von: kleinerDrache am 27 Oktober 2016, 16:56:23
ok hat sich anscheinend erledigt.
Hab nochmal alles was mit MySensors zu tun hat aus FHEM entfernt. Diesmal mit eventTypes löschen (flush und clear) dann kann ich alles neu einrichten und Inclusion Funktioniert wieder.
[...]
Denke wenn liegt es an der ConfigDB oder den eventTypes????? (LogDB bekommt keine Werte von MySensors)
Also jetzt funktioniert wieder alles mit der Development-Dateien? Kannst du mir vielleicht einen Auszug des gelöschtem Inhalts per PM senden?
Zitat von: Omega am 27 Oktober 2016, 21:36:24
@Hauswart
Du übernimmst ja gerade die löbliche Aufgabe zur Anpassung an die aktuelle Lib :) .
Dazu hätte ich gerne noch folgenden Wunsch (wenn ohne zu großen Aufwand umsetzbar): mich stört immer wieder mal, dass ich nicht wirklich sehen kann, ob das Gateway noch ,,lebt". Momentan behelfe ich mir damit, die Sensoren nach (ausbleibenden) Meldungen abzufragen. Lieber wäre mir aber ein Reading im Gateway, dass regelmäßig aktualisiert wird (Timestamp) und damit dann auch geprüft werden könnte.
@Holger ich muss mal schauen... ich bin jetzt nicht so der Perl Programmierer :D eventuell wäre dies ein Job für Norbert :)
@Hauswart
Sorry das mit dem schicken wird nix nutze ConfigDB da ist das weg wenn Ichs lösche. Gibt keine Datei mehr wo das gespeichert wird ich kann versuchen das nochmal zu provozieren und dann den kram rauskopieren aus der Datenbank.
Zitat von: kleinerDrache am 28 Oktober 2016, 08:32:16
@Hauswart
Sorry das mit dem schicken wird nix nutze ConfigDB da ist das weg wenn Ichs lösche. Gibt keine Datei mehr wo das gespeichert wird ich kann versuchen das nochmal zu provozieren und dann den kram rauskopieren aus der Datenbank.
Okay schade. Nein kein Problem, wenn es jetzt läuft ist gut.
Zitat von: gloob am 27 Oktober 2016, 22:06:14
Die Version des Gateways muss immer höher sein als die des Sensors. Ich habe hier ein Gateway mit 2.0 Version laufen und Sensoren sowohl mit 1.5.4 und 2.0, selbst Mischbetrieb bei den Sensoren ist möglich.
Update mal das Gateway auch auf die 2.0 Version. Dann sollte es klappen.
Jawohl, hat geklappt. Es hat ein bisschen gedauert (und ich musste Arduino 1.6.12 installieren) damit der Gateway Sketch kompiliert wurde. Naja, aber jetzt funktioniert es.
Die Sensoren werden aber nur nach einem Reset des Gateways erkannt oder geht das auch anders?
Danke + Gruß
PeMue
Zitat von: Floca am 21 Oktober 2016, 00:13:14
Hat noch jemand das Problem, dass ein Node als Repeater mit ID auftaucht? Ist das normal?
Habe das Problem erst seit der neuen beta...
Der Repeater (State: OK) der auftaucht wenn man ein Gateway definiert scheint ja auch normal zu sein.
Ist bei mir seit ich den Sketch mit der MySensors library v2.0.0 kompiliert habe auch so.
Gruß PeMue
liegt daran das seit 2.0 sowohl Gateway als auch Repeater eigene Sensoren haben können und jeder Node auch als Repeater dienen kann.
Naja, so ganz warm werde ich mit den MySensors Knoten noch nicht.
Ich möchte die Radio ID automatisch vergeben lassen, aber manchmal klappt das nicht.
Für meine zwei Sensbender Micro habe ich mal den Speicher gelöscht und den Sketch noch einmal aufgespielt. Wann dann fhem mit dem Pairing der Sensoren beginnt, ist mir nicht so ganz klar.
Meine Vermutung:
- Gateway in den inclusion-mode versetzen
- den Sensor (node) hart resetten, dann sollte es klappen.
Ob man das Gateway aus- bzw. wieder einstecken muss, weiß ich nicht.
Für die Versorgungsspannung wollte ich eigentlich noch die Spannung anzeigen lassen, allerdings klappt das nicht. Mein Sketch anbei, vielleicht hat einer eine Idee. Ich habe mir jetzt dafür aus dem Batterylevel ein userreadings gebaut, aber sauber ist das m.E. nicht.
Danke + Gruß
PeMue
Wegen der ID Vergabe könnte ich auch manchmal verzweifeln (sollte eigentlich Automatisch gehen aber wie schon bemerkt geht nicht immer) ich vergeb meine immer im Node-Sketch. Eigentlich soll man am Gateway "Inklusion Button" drücken dann lauscht der Gatway die im Gateway-Sketch eingestellte Zeit auf "Presentations" der Nodes. Die werden nur wärend des Bootvorgangs gesendet (wie bei HM und Co mit dem Pairing). Man kann aber auch das Attibut "Inklusion" Im FHEM Gateway Device dauerhaft auf "on" stellen dann fällt das Button drücken weg und neu eingeschaltete Nodes werden direkt angelegt.
Wegen Battery-Status:
Du legst in deinem Sketch eine extra Message dafür an was unnötig ist. Eine Spannungsangabe wird eh nicht übertragen sondern nur der %-wert. Schau dir mal das "BatteryPoweredNode" in den Beispielen an. Ist zwar für Messung am Analogport sollte aber auch mit der Badgap-Messung funktionieren wie du sie einbaust ist ja nur eine andere Datenquelle.
Du willst DualOptiBoot und Hardware Signing nutzen sehe ich das richtig ?
Edit:ok hatte mir die sensbeder noch nie angeschaut die haben das alles schon onboard.(extra speicher und den ATSHA)
Ich habe das Problem dass mein MySensors Temperatursensor nach ein paar Stunden Arbeit sich anscheinend aufhängt und nur nach einer Stromunterbrechung sich wieder mit dem MySensors Gateaway (Serial) verbindet. Beide sind in der Version 2.0
Tritt das bei jemandem auch auf?
Oder möchtest du das so haben ? (siehe Bild)
wenn ja hab mal den Sketch angehängt (Batterie aber per Spannungsteiler gemessen)
@borzo83
Wie weit ist dein Sensor vom Gateway Entfernt ?
Ich messe die Batteriespannung intern, ohne zusätzliche Beschaltung und so wird es im Sensebender Micro Sketch auch gemacht. Klappt bei mir mit meinen eigenen Sensoren auch wunderbar.
/*******************************************
*
* Internal battery ADC measuring
*
*******************************************/
long readVcc() {
// Read 1.1V reference against AVcc
// set the reference to Vcc and the measurement to the internal 1.1V reference
#if defined(__AVR_ATmega32U4__) || defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
ADMUX = _BV(REFS0) | _BV(MUX4) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
#elif defined (__AVR_ATtiny24__) || defined(__AVR_ATtiny44__) || defined(__AVR_ATtiny84__)
ADMUX = _BV(MUX5) | _BV(MUX0);
#elif defined (__AVR_ATtiny25__) || defined(__AVR_ATtiny45__) || defined(__AVR_ATtiny85__)
ADcdMUX = _BV(MUX3) | _BV(MUX2);
#else
ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
#endif
delay(2); // Wait for Vref to settle
ADCSRA |= _BV(ADSC); // Start conversion
while (bit_is_set(ADCSRA,ADSC)); // measuring
uint8_t low = ADCL; // must read ADCL first - it then locks ADCH
uint8_t high = ADCH; // unlocks both
long result = (high<<8) | low;
result = 1125300L / result; // Calculate Vcc (in mV); 1125300 = 1.1*1023*1000
return result; // Vcc in millivolts
}
Hallo kleinerDrache,
Zitat von: kleinerDrache am 30 Oktober 2016, 14:35:33
Wegen Battery-Status:
Du legst in deinem Sketch eine extra Message dafür an was unnötig ist. Eine Spannungsangabe wird eh nicht übertragen sondern nur der %-wert.
ich würde aber gerne (wie bei Homematic) ein zusätzliches Reading haben. Allerdings wird das irgendwie nicht übertragen, obwohl autocreate für das Multimeter Device Strom, Spannung und Impedanz erzeugt. Hast Du mir eine Idee, wie ich das machen muss?
Danke + Gruß
PeMue
Also ich habe es wie folgt umgesetzt. Dann bekommt man die Prozente und den Spannungswert.
Global:
MyMessage msgBatt(BATT_SENSOR, V_VOLTAGE);
Presentation:
present(BATT_SENSOR, S_POWER);
/********************************************
*
* Sends battery information (battery percentage)
*
* Parameters
* - force : Forces transmission of a value
*
*******************************************/
void sendBattLevel(bool force)
{
if (force) lastBattery = -1;
long vcc = readVcc();
if (vcc != lastBattery) {
lastBattery = vcc;
#ifdef BATT_SENSOR
float send_voltage = float(vcc)/1000.0f;
delay(senddelay);
send(msgBatt.set(send_voltage,3));
#endif
// Calculate percentage
vcc = vcc - 1900; // subtract 1.9V from vcc, as this is the lowest voltage we will operate at
long percent = vcc / 14.0;
delay(senddelay);
sendBatteryLevel(percent);
transmission_occured = true;
}
}
Und folgendes in FHEM
attr devicename mapReading_energy199 199 voltage
Hm, genau so habe ich es auch umgesetzt. Da legt fhem dann power, energy und noch was an. Aber ich bekomme keine Readings rein. Daher habe ich folgendes definiert:
global:
present(CHILD_ID_BATT,S_MULTIMETER);
Aber auch da geht nichts. Kannst Du bitte mal Deine fhem Definition posten?
Danke + Gruß
Peter
So sieht bei mir eine komplette Konfiguration für einen Sensor aus:
define MYSENSOR_TEST MYSENSORS_DEVICE 9
attr MYSENSOR_TEST IODev mysensor_gateway
attr MYSENSOR_TEST mapReading_energy199 199 voltage
attr MYSENSOR_TEST mapReading_humidity2 2 humidity
attr MYSENSOR_TEST mapReading_temperature1 1 temperature
attr MYSENSOR_TEST mode node
attr MYSENSOR_TEST version 2.0.0
Und so sehen dann die Readings aus:
SKETCH_NAME RedBoard 2016-10-30 16:57:51
SKETCH_VERSION 2.0 2016-10-30 16:57:51
batterylevel 106 2016-10-30 16:59:54
energy199 3.389 2016-10-30 16:59:54
humidity2 55 2016-10-30 16:59:54
parentId 0 2016-10-30 16:57:51
temperature1 25.1 2016-10-30 16:59:54
Irgendwas scheint da aber in FHEM mit dem autocreate noch nicht richtig zu funktionieren.
Und bei mir mit o.g. Definition bzw. der ID 3:
# sensebender micro board on top of solar storage
define UG_Heizung_sensor MYSENSORS_DEVICE 101
attr UG_Heizung_sensor IODev PMMySGW02
attr UG_Heizung_sensor mapReading_temperature 1 temperature
attr UG_Heizung_sensor mapReading_humidity 2 humidity
attr UG_Heizung_sensor mapReading_voltage 3 voltage
attr UG_Heizung_sensor mapReading_current 3 current
attr UG_Heizung_sensor mapReading_impedance 3 impedance
attr UG_Heizung_sensor mode node
attr UG_Heizung_sensor room MySensors
attr UG_Heizung_sensor version 2.0.0
attr UG_Heizung_sensor userReadings batteryvoltage { sprintf("%5.3f", (((ReadingsVal("$name", "batterylevel", 0)) * 14 + 1900) / 1000));; }
attr UG_Heizung_sensor stateFormat T:temperature, H:humidity, V: batteryvoltage
wobei es kein Reading namens voltage gibt (siehe Anhang). Daher habe ich mir ein UserReading gebaut, was aus dem Prozentwert die Spannung berechnet ...
Schau mal Da in den Sketch:
Zitat von: kleinerDrache am 30 Oktober 2016, 16:26:33
Oder möchtest du das so haben ? (siehe Bild)
wenn ja hab mal den Sketch angehängt (Batterie aber per Spannungsteiler gemessen)
@borzo83
Wie weit ist dein Sensor vom Gateway Entfernt ?
define aus Fhem: schwierig hab immer noch nicht raus gefunden wie ich den aus der ConfigDB ziehen kann,aber ich häng aber mal ein bild vom Sensor an und hier noch der List von dem Ding:
Internals:
CFGFN
DEF 5
IODev MySensors_Gateway
NAME bz_Bewegung
NR 177
STATE off
TYPE MYSENSORS_DEVICE
ack 0
protocol 2.0.0
radioId 5
repeater 0
Readings:
2016-10-30 15:52:50 SKETCH_NAME Bewegungsmelder
2016-10-30 15:52:50 SKETCH_VERSION 1.2
2016-10-30 15:53:03 batterylevel 62
2016-10-30 15:52:50 parentId 0
2016-10-30 17:02:34 tripped1 off
2016-10-30 15:53:03 voltage 4.04
Readingmappings:
0:
14:
name impedance
38:
name voltage
39:
name current
1:
15:
name armed1
16:
name tripped1
Sensormappings:
0:
receives:
sends:
16
15
1:
receives:
sends:
16
15
10:
receives:
sends:
6
7
11:
receives:
sends:
11
12:
receives:
sends:
12
14
13:
receives:
sends:
17
18
14:
receives:
sends:
45
21
0
15:
receives:
sends:
13
43
16:
receives:
sends:
23
37
17:
receives:
sends:
18:
receives:
sends:
19:
receives:
36
sends:
36
2:
receives:
sends:
16
15
20:
receives:
32
sends:
33
21:
receives:
sends:
34
35
22:
receives:
sends:
37
43
23:
receives:
48
24
25
26
27
28
sends:
48
24
25
26
27
28
24:
receives:
sends:
37
43
25:
receives:
sends:
19
20
26:
receives:
40
17
sends:
40
17
27:
receives:
41
17
sends:
41
17
28:
receives:
40
sends:
40
29:
receives:
sends:
45
44
21
46
22
3:
receives:
2
17
sends:
2
17
30:
receives:
sends:
38
39
14
31:
receives:
sends:
2
16
32:
receives:
sends:
16
15
33:
receives:
sends:
37
16
15
34:
receives:
sends:
37
16
15
35:
receives:
sends:
37
16
15
36:
receives:
47
sends:
47
37:
receives:
sends:
34
35
38:
receives:
sends:
49
39:
receives:
sends:
0
51
52
53
2
4:
receives:
2
3
17
sends:
2
3
17
5:
receives:
29
30
31
3
sends:
3
6:
receives:
sends:
0
42
7:
receives:
sends:
1
8:
receives:
sends:
4
5
9:
receives:
sends:
8
9
10
Sets:
reboot
time
Typemappings:
0:
type temperature
1:
type humidity
10:
type direction
11:
type uv
12:
type weight
13:
type distance
14:
type impedance
15:
type armed
Val:
0 off
1 on
16:
type tripped
Val:
0 off
1 on
17:
type power
18:
type energy
19:
type button_on
2:
type status
Val:
0 off
1 on
20:
type button_off
21:
type hvacflowstate
22:
type hvacspeed
23:
type brightness
Range:
max 100
min 0
step 1
24:
type value1
25:
type value2
26:
type value3
27:
type value4
28:
type value5
29:
type up
3:
type percentage
Range:
max 100
min 0
step 1
30:
type down
31:
type stop
32:
type ir_send
33:
type ir_receive
34:
type flow
35:
type volume
36:
type lockstatus
Val:
0 off
1 on
37:
type level
38:
type voltage
39:
type current
4:
type pressure
40:
type rgb
41:
type rgbw
42:
type id
43:
type unitprefix
44:
type hvacsetpointcool
45:
type hvacsetpointheat
46:
type hvacflowmode
47:
type text
48:
type custom
49:
type position
5:
type forecast
Val:
0 stable
1 sunny
2 cloudy
3 unstable
4 thunderstorm
5 unknown
50:
type irrecord
51:
type ph
52:
type orp
53:
type ec
54:
type var
55:
type va
56:
type powerfactor
6:
type rain
7:
type rainrate
8:
type wind
9:
type gust
Attributes:
IODev MySensors_Gateway
mapReading_armed1 1 armed
mapReading_current 0 current
mapReading_impedance 0 impedance
mapReading_tripped1 1 tripped
mapReading_voltage 0 voltage
mode node
room Badezimmer
stateFormat tripped1
version 2.0.0
Zitat von: kleinerDrache am 30 Oktober 2016, 16:26:33
@borzo83
Wie weit ist dein Sensor vom Gateway Entfernt ?
Nicht so weit, ca. 7 Meter auf dem gleichen Stockwerk.
Es bricht sporadisch ab, mal nach ein paar Stunden, mal nach einem ganzen Tag.
Erst raus und reinstecken des Temperatursensors bringt den Sensor zum Neuaufbau der Verbindung mit dem FHEM Gateaway.
Zitat von: borzo83 am 30 Oktober 2016, 17:07:13
Nicht so weit, ca. 7 Meter auf dem gleichen Stockwerk.
Es bricht sporadisch ab, mal nach ein paar Stunden, mal nach einem ganzen Tag.
Erst raus und reinstecken des Temperatursensors bringt den Sensor zum Neuaufbau der Verbindung mit dem FHEM Gateaway.
Hast du einen Kondensator am NRF24L01 oder was für ein Board verwendest du?
Zitat von: PeMue am 30 Oktober 2016, 17:05:53
Und bei mir mit o.g. Definition bzw. der ID 3:
# sensebender micro board on top of solar storage
define UG_Heizung_sensor MYSENSORS_DEVICE 101
attr UG_Heizung_sensor IODev PMMySGW02
attr UG_Heizung_sensor mapReading_temperature 1 temperature
attr UG_Heizung_sensor mapReading_humidity 2 humidity
attr UG_Heizung_sensor mapReading_voltage 3 voltage
attr UG_Heizung_sensor mapReading_current 3 current
attr UG_Heizung_sensor mapReading_impedance 3 impedance
attr UG_Heizung_sensor mode node
attr UG_Heizung_sensor room MySensors
attr UG_Heizung_sensor version 2.0.0
attr UG_Heizung_sensor userReadings batteryvoltage { sprintf("%5.3f", (((ReadingsVal("$name", "batterylevel", 0)) * 14 + 1900) / 1000));; }
attr UG_Heizung_sensor stateFormat T:temperature, H:humidity, V: batteryvoltage
wobei es kein Reading namens voltage gibt (siehe Anhang). Daher habe ich mir ein UserReading gebaut, was aus dem Prozentwert die Spannung berechnet ...
Wie wird bei euch denn die Batteriespannung im Arduino Sketch übertragen und welchen Message-Typ nutzt ihr?
Hm hatte damit auch schon mal Probleme ein ändern der Sende Channels hat
1. Die reichweite gewaltig erhöht und
2. die abbrüche waren auch passe
Standartmässig läuft MySensors auf Channel 76 also 2476 Mhz. Da kommt mann schonmal mit älteren Wlan Geräten in konflickt. Hier mal Die Tabelle für die möglichen anderen Channels.
/**
* @def MY_RF24_CHANNEL
* @brief RF channel for the sensor net, 0-125.
* Frequence: 2400 Mhz - 2525 Mhz Channels: 126
* http://www.mysensors.org/radio/nRF24L01Plus.pdf
* 0 => 2400 Mhz (RF24 channel 1)
* 1 => 2401 Mhz (RF24 channel 2)
* 76 => 2476 Mhz (RF24 channel 77)
* 83 => 2483 Mhz (RF24 channel 84)
* 124 => 2524 Mhz (RF24 channel 125)
* 125 => 2525 Mhz (RF24 channel 126)
* In some countries there might be limitations, in Germany for example only the range 2400,0 - 2483,5 Mhz is allowed
* http://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/Sachgebiete/Telekommunikation/Unternehmen_Institutionen/Frequenzen/Allgemeinzuteilungen/2013_10_WLAN_2,4GHz_pdf.pdf
*/
Hab Ich aus der Config.h rauskopiert. Bei mir läuft das ganze auf Channel 0 also 2400 Mhz bisher keine schwierigkeiten.
Zitat von: gloob am 30 Oktober 2016, 17:08:54
Hast du einen Kondensator am NRF24L01 oder was für ein Board verwendest du?
Ja ich verwende das NRF24L01 Modul, allerdings ohne Kondensator. Wo sollte da ein Kondensator hin?
Zitat von: borzo83 am 30 Oktober 2016, 17:17:18
Ja ich verwende das NRF24L01 Modul, allerdings ohne Kondensator. Wo sollte da ein Kondensator hin?
Ich habe bei mir den Kondensator auf den Senorplatinen zwischen Versorgungsspannung und Masse, relativ nah an den Modulen drauf.
Du kannst aber auch einen Kondensator direkt auf den NRF Modulen zwischen + und - löten
hab ich auch aber direkt am NRF nen kleinen Elko mit 10 Microfarad zwischen GND und VCC.
Nutz Du NRF24L01 oder NRF24L01+ Module das ist ein unterschied
Zitat von: gloob am 30 Oktober 2016, 17:18:31
Ich habe bei mir den Kondensator auf den Senorplatinen zwischen Versorgungsspannung und Masse, relativ nah an den Modulen drauf.
Du kannst aber auch einen Kondensator direkt auf den NRF Modulen zwischen + und - löten
Danke für den Tip, ich probiere es mal mit einem Kondensator und werde berichten ob es stabiler läuft.
Zitat von: gloob am 30 Oktober 2016, 17:12:38
Wie wird bei euch denn die Batteriespannung im Arduino Sketch übertragen und welchen Message-Typ nutzt ihr?
Ist quasi der MySensors Standard Sketch:
Ich habe die Message ID auf 3 gesetzt:
// Uncomment the line below, to transmit battery voltage as a normal sensor value
#define CHILD_ID_BATT 3
#ifdef CHILD_ID_BATT
MyMessage msgBatt(CHILD_ID_BATT, V_VOLTAGE);
#endifin presentation:
#ifdef CHILD_ID_BATT
//present(CHILD_ID_BATT,S_POWER);
present(CHILD_ID_BATT,S_MULTIMETER);
#endif
und die Sendefunktion:
/************************************************
* Sends battery information (battery percentage)
*
* Parameters
* - force : Forces transmission of a value
***********************************************/
void sendBattLevel(bool force)
{
if (force) lastBattery = -1;
long vcc = readVcc();
if (vcc != lastBattery)
{
lastBattery = vcc;
#ifdef CHILD_ID_BATT
float send_voltage = float(vcc)/1000.0f;
Serial.print("battery voltage: ");Serial.println(send_voltage);
send(msgBatt.set(send_voltage,3));
#endif
// Calculate percentage
vcc = vcc - 1900; // subtract 1.9 V from vcc, as this is the lowest voltage we will operate at
long percent = vcc / 14.0; //(2500-1900)*100
Serial.print("battery level: ");Serial.println(percent);
sendBatteryLevel(percent);
transmission_occured = true;
}
}
/***********************************************/Wie schon gesagt, die Attribute werden von fhem angelegt, aber die Readings kommen nicht.
Es geht weder mit S_POWER noch mit S_MULTIMETER >:(
Was passiert wenn du in FHEM folgende Attribute entfernst:
attr UG_Heizung_sensor mapReading_current 3 current
attr UG_Heizung_sensor mapReading_impedance 3 impedance
und in der Presentation auf S_POWER stellst?
Ich hatte auch Probleme wenn es mehrere mapReadings gab für eine Id. Das Autocreate macht da irgendwie Mist.
Zitat von: gloob am 30 Oktober 2016, 17:27:07
Was passiert wenn du in FHEM folgende Attribute entfernst:
attr UG_Heizung_sensor mapReading_current 3 current
attr UG_Heizung_sensor mapReading_impedance 3 impedance
und in der Presentation auf S_POWER stellst?
Nichts, bleibt wie es ist (MySensors Library 2.0.0). Wenn ich aber einen Sketch passend zur Library 1.5.x nehme, dann geht es. Warum auch immer >:(
Das Sensebender Micro ist auch so ein komisches Ding:
- scheinbar ist es auf 1 MHz konfiguriert
- aber dann passt die Baudrateneinstellung nicht mehr >:( >:( >:(
Naja, jetzt habe cih einen mal mit 1.5 und den anderen mit 2.0 Sketch bespielt. Mal sehen, wie die Reichweite ist.
Gruß PeMue
Pack mal in den Sensbender Sketch oben
#define MY_BAUD_RATE 9600
mit rein damit kannst du die Serial Baudrate ändern.
Die Extra Attribs kommen von Gewählten Sensor Type, die werden immer mitgesendet ob du die nutzt oder nicht, aber nur die mit Daten werden in die Readings übernommen. Entfern mal den Sensor komplett aus FHEM Lösche das EEPROM des Sensors und lösch im FHEM die eventTypes. Hatte da auch mal Probleme mit weil ich die ID schon mal verwendet hatte. Ob das jetzt am EEPROM oder den eventTypes lag weis ich nicht genau aber das hat geholfen.
Der Sensebender schaltet nach x Übertragungen automatisch von 8Mhz auf 1Mhz runter um Strom zu sparen. Das kannst du aber im Sketch deaktivieren.
Zitat von: gloob am 01 November 2016, 18:21:41
Der Sensebender schaltet nach x Übertragungen automatisch von 8Mhz auf 1Mhz runter um Strom zu sparen.
Danke für die Infos. Ich habe beim Start die LED 0,2 s blinken lassen. Wenn ich für 8 MHz kompiliere, dann dauert das relativ lange. Daher vermute ich, dass das Teil sofort im 1 MHz Modus loslegt. Aber ich schau mir ma die Fuses im Bootloader an ...
Gruß PeMue
Hallo zusammen,
ich bin auch gerade dabei, mich mal ein wenig an MySensors heranzutasten.
Hab jetzt ein Serial-Gateway und ein node mit einem Phototransistor als Helligkeitsmesser.
So weit funktioniert das auch und fhem bekommt auch Daten, ABER wenn ich den RPi reboote oder auch nur fhem neu starte, kommt vom node nichts mehr in fhem an.
Ich muss dann erst den node ebenfalls resetten, damit in fhem wieder Daten geliefert werden.
Hatte testweise auch mal einen node mit PIR und der verhielt sich ebenfalls so.
Da ich mir nicht vorstellen kann, dass das ein normales Verhalten ist, wollte ich mal nachfragen, ob vlt jemand weiss, woran das liegen könnte ?
Dankeschön und viele Grüße,
Lars
Zitat von: Feuerpfeil am 04 November 2016, 12:58:58
oder auch nur fhem neu starte, kommt vom node nichts mehr in fhem an.
Habe eben mal den Test gemacht mit
shutdown restartJedenfalls bei mir ist das nicht so, es wird weiter empfangen (allerdings "liebt" mein GW den status "startup complete", was mir nicht ganz normal vorkommt, aber was soll's...).
Welche Mysensors-Version nutzt Du?
Ansonsten würde ich auf Probleme mit der Funkverbindung tippen. Hast Du die Möglichkeit, eine der Nodes näher beim GW zu betreiben zum Testen?
Gruß,
Beta-User
Zitat von: Beta-User am 04 November 2016, 20:39:06
Ansonsten würde ich auf Probleme mit der Funkverbindung tippen. Hast Du die Möglichkeit, eine der Nodes näher beim GW zu betreiben zum Testen?
Danke für den Tipp ! :)
Es scheint tatsächlich daran zu liegen.
Das hätte ich bei diesem Phänomen nicht vermutet.
Hatte weiter oben gelesen, dass sich die Frequenzen ein wenig anpassen lassen.
Das werde ich dann die Tage mal ausprobieren. Ansonsten habe ich auch noch von einem alten Router eine Wlan Antenne.
Die lässt sich bestimmt auch ans Gateway basteln.
VG
Lars
@Beta-User
Solange du nicht Debug aktivierst oder Sensoren mit an den Gateway anschließt kommt da nicht mehr als Der "Lieblings Status" ;)
@Feuerpfeil
wegen der Reichweite : hast du Kondensatoren an den Funkmodulen ? Der Arduino liefert gerade wenn der an einem Handynetzteil oder PC-Anschluss läuft eine ziemlich "verrauschte" Spannung (Stichwort Schaltnetzteil) . Das geht ziemlich auf die Reichweite das kannst du einfach prüfen "Batterien drann statt Netzteil oder PC". Wenns dann nicht läuft kannst du halt noch den Kanal der NRF-Module ändern (siehe mein Beitrag etwas früher)
Zitat von: kleinerDrache am 05 November 2016, 15:58:25
@Beta-User
Solange du nicht Debug aktivierst oder Sensoren mit an den Gateway anschließt kommt da nicht mehr als Der "Lieblings Status" ;)
Danke, da wäre ich jetzt nicht drauf gekommen 8).
Zitat von: kleinerDrache am 05 November 2016, 15:58:25
@Feuerpfeil
wegen der Reichweite : hast du Kondensatoren an den Funkmodulen ? Der Arduino liefert gerade wenn der an einem Handynetzteil oder PC-Anschluss läuft eine ziemlich "verrauschte" Spannung (Stichwort Schaltnetzteil) . Das geht ziemlich auf die Reichweite das kannst du einfach prüfen "Batterien drann statt Netzteil oder PC". Wenns dann nicht läuft kannst du halt noch den Kanal der NRF-Module ändern (siehe mein Beitrag etwas früher)
Zitat von: Feuerpfeil am 05 November 2016, 13:27:10
Danke für den Tipp ! :)
Es scheint tatsächlich daran zu liegen.
Das hätte ich bei diesem Phänomen nicht vermutet.
Hatte weiter oben gelesen, dass sich die Frequenzen ein wenig anpassen lassen.
Hallo Lars,
Das mit dem Kondensator ist wirklich wirksamer als die Frequenz!
Du kannst es auch noch mit zwei anderen "Tricks (https://forum.fhem.de/index.php/topic,51325.msg450195.html#msg450195)" versuchen: den Funkchip schirmen (Isolierband:Alufolie:Isolierband drumherum, natürlich nicht um die Antenne) und/oder den PA_LEVEL_xxx etwas erhöhen (so Du ausreichend Power hast).
Angeblich ist der PA_LEVEL in der 2.0 Lib eh immer auf MAX. Hat bei mir aber nicht funktioniert so das ich das #define dazu in jedem Sketch extra aktivieren musste.
Das mit der Alufolie kante ich auch noch nicht danke dafür probier ich aus.
Zitat von: kleinerDrache am 05 November 2016, 16:11:01
Angeblich ist der PA_LEVEL in der 2.0 Lib eh immer auf MAX.
In dem Beispiel-Code auf Github sind die aktuellen seriellen GW's standardmäßig per individuellem Sketch auf "LOW", die Einstellung "MAX" aus der generellen "Myconfig.h" wird daher ohne Anpassung im Sketch überschrieben.
Zitat von: kleinerDrache am 05 November 2016, 15:58:25
@Beta-User
Solange du nicht Debug aktivierst oder Sensoren mit an den Gateway anschließt kommt da nicht mehr als Der "Lieblings Status" ;)
Gestern etwas rumgetestet und dazu folgende Ergebnisse, nur für den Fall, dass jemand über dasselbe stolpert: Das "Startup complete" ist vermutlich tatsächlich eine Folge von Reboots und hat nichts damit zu tun, ob Debug aktiviert ist oder nicht. Insbesondere die seriellen 2.0.1-beta-GW's neigen zu häufigen Reboots, Ursache ist vermutlich eine Inkompabilität mit neueren Versionen der Board-Definitionen in der Arduino-IDE. Werde heute abend mal Testen, ob ein "downgrade your AVR board defs to 1.6.11" wirklich hilft, Fundstellen: hier (https://forum.mysensors.org/topic/5154/serialgateway-is-rebooting-on-relay/12) und hier (https://forum.mysensors.org/topic/4680/mysensors-2-0-ethernet-gateway-atmega-w5100-restart-all-time/2).
Aber immerhin funktioniert jetzt das meiste meines MySensors-Netzes wieder :) :) :), das war echt nicht spaßig!
...dein Username ist Programm
scnr
Gesendet von meinem Toaster.
Zitat von: micky0867 am 07 November 2016, 13:00:24
...dein Username ist Programm
scnr
Gesendet von meinem Toaster.
...was ein Zufall 8)...
Im Ernst: Bei vielen open-source-Projekten ist es so, dass die jeweilige Beta die Version ist, die am besten gepflegt ist. Sobald die "stable" raus ist, kümmert sich keiner der Entwickler mehr um die Behebung noch vorhandener Bugs in dieser Version, Beta ist nicht selten sogar stabiler (leider eben nicht immer, auch wenn es in dem konkreten Fall eher mit der Weiterentwicklung bei Arduino und nicht bei MySensors zu tun hat, daher auch der Fehler (?) in der aktuellen stable).
Auch wenn nicht alles in der MySensors-beta schon perfekt ist, für das, was ich machen will, brauche ich saubere SPI-Abläufe und keine Bugs in der Presentation() (https://forum.fhem.de/index.php/topic,58620.0.html), also die beta....
BTW: auch bei FHEM handelt es sich m.E. um eine beta ;), jedenfalls was viele der Module angeht. Also willkommen im Club!
Zitat von: Beta-User am 07 November 2016, 11:00:21
Insbesondere die seriellen 2.0.1-beta-GW's neigen zu häufigen Reboots, Ursache ist vermutlich eine Inkompabilität mit neueren Versionen der Board-Definitionen in der Arduino-IDE. Werde heute abend mal Testen, ob ein "downgrade your AVR board defs to 1.6.11" wirklich hilft, Fundstellen: hier (https://forum.mysensors.org/topic/5154/serialgateway-is-rebooting-on-relay/12) und hier (https://forum.mysensors.org/topic/4680/mysensors-2-0-ethernet-gateway-atmega-w5100-restart-all-time/2).
Ich benutze das Ethernet-Gateway mit der MYSENSOR 2.0 Stable Version, hier tritt der Fehler ebenso auf. Ein Downgrade der Board-defs auf 1.6.11 funktioniert und das Gateway ist danach absolut stabil.
VG Sven
Ich nutze keinen seriellen GW ;) deswegen ist mir das wohl nie aufgefallen, in den Individuellen Sketches steht bei mir nur das mindeste an #defines drin (also auch eigentlich kein MAX PA-LEVEL) trotzdem muss ich das setzen obwohl in der globalen Config.h schon max definiert ist. Sonst nutz MySensors halt nur LOW warum auch immer (nutze übrigens die 2.0 Stabel). Aber wie schon erwähnt ist halt alles "BETA".
Trotzdem ist MySensors ein relativ gutes und stabiles System wie ich finde hoffe das geht noch lange weiter ;)
Zitat von: kleinerDrache am 07 November 2016, 15:26:32
in den Individuellen Sketches steht bei mir nur das mindeste an #defines drin
Das ist m.E. auch die beste Vorgehensweise; wenn man zu viel selbst dran schraubt, wird es im Falle allgemeiner updates tendenziell unübersichtlicher. Was ich allerdings praktisch immer mache, ist die NodeID hart zu vergeben.
Zitat von: kleinerDrache am 07 November 2016, 15:26:32
Sonst nutz MySensors halt nur LOW warum auch immer
Das ist seltsam (ich nehme an, Du hast den ESP?). In den Sketchen steht -jedenfalls auf die Schnelle - nix von PA_LEVEL, das sollte anders aus der Myconfig.h kommen ???.
Zitat von: kleinerDrache am 07 November 2016, 15:26:32
Aber wie schon erwähnt ist halt alles "BETA".
Trotzdem ist MySensors ein relativ gutes und stabiles System wie ich finde hoffe das geht noch lange weiter ;)
Die Arduinos sind schon eine sehr solide Basis und MySensors als Baukasten m.E. auch sehr klar und logisch aufgebaut (wenn ich je mal einen Programmier-Kurs anbieten muß, dann würde ich das als "Anschauungsmaterial" für den Fortgeschrittenenteil nehmen!), daher hatte ich von Anfang an eine Schwäche für die 2.0.0-beta, als 1.5.4 noch "stable" war; da waren die Sketche nämlich - für mich als Anfänger - sehr viel leichter zu lesen 8).
Zitat von: SvenJust am 07 November 2016, 13:18:58
Ich benutze das Ethernet-Gateway mit der MYSENSOR 2.0 Stable Version, hier tritt der Fehler ebenso auf. Ein Downgrade der Board-defs auf 1.6.11 funktioniert und das Gateway ist danach absolut stabil.
Danke für die Info, nachdem auch meine jüngst wieder zurückgeflashten 2.0.0-(ohne beta)-GW's nicht mehr in "connected" gehen wollten (identische HW!), und das Problem sowohl bei den seriellen wie den Ethernet-GW's gemeldet war, war ein Power-Problem eher nicht wahrscheinlich (auch wenn der NRF-Treiber wohl jüngst gründlich renoviert wurde und evtl. mehr Strom zieht). Dann kann ich jetzt (hoffentlich) wirklich per default die Beta produktiv einsetzen!
Gruß, Beta-User
gesendet von einem OS einer seltsamen Firma
ZitatDas ist m.E. auch die beste Vorgehensweise; wenn man zu viel selbst dran schraubt, wird es im Falle allgemeiner updates tendenziell unübersichtlicher. Was ich allerdings praktisch immer mache, ist die NodeID hart zu vergeben.
Jup mach ich auch so , allerdings ist bei mir mittlerweile noch der PA_LEVEL und der CHANNEL dazugekommen.(wegen Reichweiten Problemen und Überschneidungen mit diversen WLAN-Signalen)
Zitat(ich nehme an, Du hast den ESP?).
Ja allerdings etwas abgewandelt (meldet sich das erstemal als WLAN-HOTSPOT kann dann konfiguriert werden und verhält sich dann wie der normale WLAN-Gateway) das mit dem gezwungenen MAX PA_LEVEL macht aber auch der standart Sketch von MySensors.
ZitatDie Arduinos sind schon eine sehr solide Basis und MySensors als Baukasten m.E. auch sehr klar und logisch aufgebaut
Da hast Du recht.
Allerdings überlege ich schon da in die Sensor-Definitionen so einige eigene Sachen einzubinden (original ist mir einfach zu unflexibel) genauso muss ich mal überlegen dem FHEM-Modul Maintainer ne PM zu schreiben ;) (Die Namensvergabe geht mal so gar nicht ;D) . Und bei dem Umfang und den Möglichkeiten die man mit MySensors hat und aufgrund des fast völlig fehlendem Deutschen Forums sollte man mal anfragen ob MySensors hier nicht einen eigenen Bereich bekommen könnte. (ist etwas mühsam sich hier was dazu zusammen zu suchen)
Zitat von: kleinerDrache am 07 November 2016, 21:33:14
Allerdings überlege ich schon da in die Sensor-Definitionen so einige eigene Sachen einzubinden (original ist mir einfach zu unflexibel) genauso muss ich mal überlegen dem FHEM-Modul Maintainer ne PM zu schreiben ;) (Die Namensvergabe geht mal so gar nicht ;D) . Und bei dem Umfang und den Möglichkeiten die man mit MySensors hat und aufgrund des fast völlig fehlendem Deutschen Forums sollte man mal anfragen ob MySensors hier nicht einen eigenen Bereich bekommen könnte. (ist etwas mühsam sich hier was dazu zusammen zu suchen)
"Eigene Sachen" klingt interessant?
Im Prinzip kann man mit MySensors die Arduino-Vorteile nutzen (autonome Entscheidungen, mehrere Sensoren an einer Node) und das Ding rechnen lassen und die Zentrale nur informieren, was passiert ist. Also z.B. einen vollwertigen Bewegungsmelder basteln, den man von der Zentrale aus konfigurieren kann, nebenbei Displaysteuerung oder oder oder...
Eines ist nur in dem Zusammenhang nicht so ganz geschickt: die Nodes brauchen seit V. 2.0.0 eine Verbindung zum GW. Das war früher wohl anders (https://forum.mysensors.org/topic/4449/how-to-disable-default-node-registration-to-the-gw).
Na ja, ich fand das auch recht unübersichtlich hier, mein (etwas angestaubter) Erkenntnisstand ist u.A. aus diesem Grund hier (https://forum.fhem.de/index.php/topic,51325.0.html) zu finden und ein paar Sketches auf Gitub (vor allem das Dallas-Temperatur-Sensor-Thema hatte es mir angetan, weil ich parallel mehrere angeschlossen habe, dem who-is-who aber nicht getraut habe). Ob es gleich einen eigenen Thread braucht, weiß ich nicht. Man könnte ja einfach spezielle Fragen auch als seperaten Thread beginnen. Es traut sich halt wohl keiner oder die Dinge sind für echte Cracks zu einfach oder die Erfahrung ist die, dass genug Leute hier mitlesen, keine Ahnung ;).
Ein vernünftiger Wiki-Artikel wäre vermutlich für viele hilfreich (evtl. auch ein weiterer Artikel mit den anderen Verwendungsmöglichkeiten der Arduinos und anderer Microcontroller, da sieht man als Anfänger ja auch den Wald vor lauter Bäumen kaum). Arbeite da gerne mit, aber mir fehlen elementare Kenntnisse z.B. bzgl. des WLAN-GW usw.
Btw: Warum das WLAN-GW der Startpunkt für viele ist, werde ich wohl nie verstehen: Ich bin auf MySensors gestoßen, weil ich nach der irrigen Annahme, ein ESP wäre für die Übertragung von Informationen der optimale Weg, etwas einfacheres brauchte 8)
Der WLAN-GW wohl, weil aufgrund sehr vielen unterstützter USB-Geräte in FHEM irgendwann selbst mit Hubs der Platzt an freien Anschlüssen etwas knapp wird ,hab hier selber nen Cubietruck der hat nur 2 ok 3 mit Adapter und mittlerweile 3 Hubs ;). ESP naja nicht schlecht aber im Endefekt einfach zu wenig nutzbare Pins (z.B. nur 1 Analogpin) und etwas sehr Stromhungrig (für Batteriebetrieb) scheidet deswegen für mich aus.
Der Arduino dagegen extrem flexibel selbst der auf MySensors immer wieder auftauchende "der hat ja nur 2 irq PINS" Spruch ist mit PinChange IRQ zu umgehen. Einfach zu Programmieren (im extremfall einfach COPY&PASTE hochladen und gut) einfache Hardware usw........
Naja könnte da jetzt noch lange drüber schwafeln *gg*
Der Wiki-Artikel ist soweit in Ordnung aber ne Überarbeitung und Erweiterung (Thema OTA) können aber nie schaden denke ich.
hmmm meinst du in Bezug Auf:
ZitatEines ist nur in dem Zusammenhang nicht so ganz geschickt: die Nodes brauchen seit V. 2.0.0 eine Verbindung zum GW. Das war früher wohl anders.
Die Registrierung am GW ?
Zitat von: kleinerDrache am 07 November 2016, 21:33:14
Ja allerdings etwas abgewandelt (meldet sich das erstemal als WLAN-HOTSPOT kann dann konfiguriert werden und verhält sich dann wie der normale WLAN-Gateway) das mit dem gezwungenen MAX PA_LEVEL macht aber auch der standart Sketch von MySensors.
Ich hätte Interesse an dem per WLAN konfigurierbaren Sketch (OTA-Update wäre noch die Sahne-Haube ;D )
Magst Du die Source posten?
sobald ich alles fertig habe gerne. im Moment hapert es noch an ein zwei stellen. Gerade das mit dem OTA klemmt weil TEK die Sources zum Bootloader noch nicht rausrückt D;
Zitat von: kleinerDrache am 07 November 2016, 21:33:14
Allerdings überlege ich schon da in die Sensor-Definitionen so einige eigene Sachen einzubinden (original ist mir einfach zu unflexibel) genauso muss ich mal überlegen dem FHEM-Modul Maintainer ne PM zu schreiben ;) (Die Namensvergabe geht mal so gar nicht ;D) .
Ich bin nicht Maintainer, aber du kennst die V_CUSTOM Variablen? Prinzipiell kannst du aber immer alle Variabelen verwenden, nur werden sie nicht automatisch angelegt im FHEM.
Welche Namensvergabe meinst du? :)
Hi,
Mal eine Frage zwischendurch:
Habe ein WLAN Gateway mit statischer IP.
Beim jedem Neustart von Fhem muss ich im devices kurz auf modify gehen damit alles wieder funzt.
Woran könnte das liegen?
Möchte nicht immer jedesmal diesen extra Schritt machen müssen.
Gesendet von meinem C6903 mit Tapatalk
@Hauswart
Ich meine den Namen den ein neuer Sensor beim anlegen von FHEM erhält. Im Normalfall MYSENSORS_ID , besser fände ich z.B. Sketchname+Version+ID wird ja von MySensors mitgesendet. Ab 10 Sensoren ist es etwas schwierig sich noch zu merken welcher Sensor welcher ist *gg*.
@Markus80
Sollte eigentlich nicht passieren. Ich weis allerdings nicht ob das Gateway eine "Hearbeat" Message sendet bei meinem ist ein Sensor (BMP280) mit verbaut der das übernimmt.
Zitat von: kleinerDrache am 08 November 2016, 11:14:46
@Hauswart
Ich meine den Namen den ein neuer Sensor beim anlegen von FHEM erhält. Im Normalfall MYSENSORS_ID , besser fände ich z.B. Sketchname+Version+ID wird ja von MySensors mitgesendet. Ab 10 Sensoren ist es etwas schwierig sich noch zu merken welcher Sensor welcher ist *gg*.
Alias vergeben? Für einzelne Readings auch Readingsproxy in Erwägung ziehen?
Zitat von: kleinerDrache am 08 November 2016, 00:31:28
sobald ich alles fertig habe gerne. im Moment hapert es noch an ein zwei stellen. Gerade das mit dem OTA klemmt weil TEK die Sources zum Bootloader noch nicht rausrückt D;
Warum tust Du Dich nicht mit Hexenmeister zusammen? M.E. gehört er zu den wirklichen MySensors-Heroes und hat dazu noch Ahnung vom ESP, die Aussichten wären also gut, dass ihr da zusammen was ans Laufen bringt! Evtl. ist es dann auch leichter TEK (tekka?) zu überzeugen, dass er sich in die Karten sehen läßt...
Zitat von: kleinerDrache am 07 November 2016, 22:55:21
Der Wiki-Artikel ist soweit in Ordnung aber ne Überarbeitung und Erweiterung (Thema OTA) können aber nie schaden denke ich.
Deinen OTA-Beitrag habe ich vorhin noch in meine Stichwortsammlung übernommen, als Wiki und Einführung für Newbies taugt es eher nicht und wäre auch auf 2.0.0 (final) anzupassen. Habe aber einen Editor-Zugriff bei ph1959 beantragt, vielleicht kann dann jemand die Infos zu ESP beisteuern?
Zitat von: kleinerDrache am 07 November 2016, 22:55:21
... die Nodes brauchen seit V. 2.0.0 eine Verbindung zum GW... Die Registrierung am GW ?
Ja, bevor die presentation()-Routine nicht durch ist (=Registrierung beim GW), startet die loop() nicht.
Gruß,
Beta-User
@kleinerdrache
Ist ein Luftdrucksensor richtig?
Gesendet von meinem C6903 mit Tapatalk
Der BMP280 ist ein kombinierter Luftdruck/Temperatur Sensor gibt noch den BME280 der hat zusätzlich noch Feuchtigkeit (sollte man bevorzugen hatte aber noch nen BMP rumliegen)
@Beta-User
Schon klar mit Alias oder sogar umbenennen aber warum son Aufwand wenn es auch per Autocreate gehen könnte ? Die passenden Daten sind ja da. Muss man dann eh nochmal anpassen wenn man z.B. mehrere Bewegungsmelder gebaut hat (Wohnzimmer/Küche......) aber man könnte wenigstens grob unterscheiden: Hab ich da jetzt nen Bewegungsmelder oder iss das ein Thermometer.
Danke für die schnelle Info :-)
Gibt es einen fertigen Sketch dafür?
Gesendet von meinem C6903 mit Tapatalk
Hallöchen,
ich muss sagen, dass für mich das Thema MySensors auch noch äußerst undurchsichtig ist.
Mich wundert es auch, dass hier nicht "so viel" darüber zu lesen ist, bzw. es nur wenige Themen gibt.
Mich persönlich verunsichert das etwas, sodass ich mich schon fast gar nicht "traue" zu fragen, weil ich denke,
dass MySensors wohl so selbsterklärend oder selbstverständlich ist. Da komme ich mir so "dumm" vor :D
Auch wenn ich ganz gute englisch Kenntnisse habe, tue ich mich schwer damit, mich durch die MySensors Homepage zu wurschteln.
Vielleicht lese ich auch nur zu oberflächlich.
Einige zusammenhängende Dinge scheinen irgendwie verstreut und auch die Beispiel Sketche auf der Homepage unterscheiden sich von denen auf Github. Teilweise haben sie auch unterschiedliche andere Dateinamen.
Ich finde es jedenfalls echt prima, dass ihr euch der Sache hier annehmt und hier immer gute Hilfestellungen leistet !!! ;)
Viele Grüße,
Lars
@kleinerDrache
Ich vermisse bei meinen Gateways auch die Möglichkeit einer Heartbeat-Funktionalität. Was für ein Sensor dranhängt, ist mir eigentlich egal - Hauptsache, dass GW spricht regelmäßig. Allerdings ist es mir nicht gelungen, einen Sketch erfolgreich aufzubauen.
Magst du bitte mal deinen Sketch posten (wenn möglich bei einem WLAN-GW), bitte auch in Verbindung mit welchen Bibliotheken. Nur dann kann man ja einigermaßen sicher sein, auch zu einem funktionierenden Exemplar zu kommen.
Danke
Holger
Zitat von: kleinerDrache am 08 November 2016, 12:41:29
Schon klar mit Alias oder sogar umbenennen aber warum son Aufwand wenn es auch per Autocreate gehen könnte ? Die passenden Daten sind ja da. Muss man dann eh nochmal anpassen wenn man z.B. mehrere Bewegungsmelder gebaut hat (Wohnzimmer/Küche......) aber man könnte wenigstens grob unterscheiden: Hab ich da jetzt nen Bewegungsmelder oder iss das ein Thermometer.
Na ja, die readings der Nodes sprechen ja auch eine klare Sprache, sobald sie angelegt sind.
Ich finde es eigentlich ganz angenehm, dass die Erstbenamsung nur nummerisch ist, dann kann ich auch nach dem aliasen im Browser leichter per Befehlszeile durchwechseln, der "Bandwurm" vorneweg wäre da hinderlich. Den Rest erledige ich eh' per "attr room xxx" und versuche, möglichst nur eine Node pro Zimmer zu haben (Kombisensoren) 8).
Zitat von: Markus80 am 08 November 2016, 12:50:22
Gibt es einen fertigen Sketch dafür?
In den MySensors-Sourcen ist derzeit nur der BMP180 drin, aber vermutlich gibt es auch eine Arduino-lib für den BPE280, der Rest ist dann einfach eine Kombination aus BMP180-MySensors-Sketch, DHT11-MySensors-Sketch und der neuen lib...
Zitat von: Feuerpfeil am 08 November 2016, 12:50:45
Mich persönlich verunsichert das etwas, sodass ich mich schon fast gar nicht "traue" zu fragen, weil ich denke,
dass MySensors wohl so selbsterklärend oder selbstverständlich ist. Da komme ich mir so "dumm" vor :D
Es geht vermutlich einigen hier so, aber wer FHEM konfiguriert bekommt, ist eher nicht zu dumm dafür, es ist nur eben nicht ganz selbsterklärend!
Zitat von: Feuerpfeil am 08 November 2016, 12:50:45
Einige zusammenhängende Dinge scheinen irgendwie verstreut und auch die Beispiel Sketche auf der Homepage unterscheiden sich von denen auf Github. Teilweise haben sie auch unterschiedliche andere Dateinamen.
Das war vor dem Wechsel zu 2.0.0 besser, die Jungs sind da aber ziemlich am überarbeiten, wird wohl wieder. Am besten: Bauanleitungen von MySensors.org, Sketche von github ;).
Zitat von: Omega am 08 November 2016, 12:54:44
@kleinerDrache
Ich vermisse bei meinen Gateways auch die Möglichkeit einer Heartbeat-Funktionalität. Was für ein Sensor dranhängt, ist mir eigentlich egal - Hauptsache, dass GW spricht regelmäßig. Allerdings ist es mir nicht gelungen, einen Sketch erfolgreich aufzubauen.
Es gibt zum einen teilweise interen Readings (z.B. für battery), Details habe ich grade aber nicht parat.
Füge doch einfach einen Dummy-Sensor ein (z.B. einen Motion), also nach Beispiel in die presentaion().
Dann in der loop() einfach alle 300000 ms Motion an bzw. ausschalten oder ein "on" senden.
Ich häng hier nochmal meinen alten GW-Sketch an der ist zwar noch ohne webconfig aber der BMP280 ist eingebunden und liefert Druck/Temperatur/Forecast. allerdings habe ich sämtliche Kommentare enfernt (mich persönlich nerven die und stören erheblich die übersicht).
Als übersicht:
ESP8266 (nodeMCU v3)
Die Sensorlib ist von Adafruit (Adafruit BMP280 + Adafruit Sensors)
MySesnors 2.0 Stabel
händisch angepasst hab ich die i2c PINS der Adafruit LIB
In der Datei Adafruit_BMP280.cpp ziemlich weit oben
bool Adafruit_BMP280::begin(uint8_t a) {
_i2caddr = a;
if (_cs == -1) {
// i2c
Wire.begin(3,1);
Da wo es rot ist müssen eure pins hin (wire doku welcher was ist) und aufpassen die GPIOS vom ESP passen nicht 1:1 auf die Arduino Pin-Nummern: siehe hier (https://github.com/esp8266/Arduino/issues/584)
@kleiner Drache:
Danke, das ist sicher für den einen oder anderen ein aufschlußreiches Beispiel, wie das im allgemeinen geht!
Zitat von: Omega am 08 November 2016, 12:54:44
Ich vermisse bei meinen Gateways auch die Möglichkeit einer Heartbeat-Funktionalität.
Hallo Holger,
irgendwie hatte ich das noch in Erinnerung, dass eine heartbeat-Funktion dazugekommen ist: https://github.com/mysensors/MySensors/releases.
Laut https://www.mysensors.org/download/sensor_api_20 gibt es
void sendHeartbeat();Das ganze sind aus Sicht von FHEM nach mein Perl-Verständnis eine sog. internal message, die allerdings noch nicht in 10_MYSENSORS_DEVICE.pm für FHEM "verdaubar" zu sein scheint; vielleicht gibt es in anderen Modulen entsprechenden Code, den man hierher "verpflanzen" könnte (auch im Sinne einer Einheitlichkeit!)?
Bei BatteryLevel funktioniert das mit den "internal Messages" schon jetzt, der entsprechende Aufruf ist
void sendBatteryLevel(uint8_t level, bool ack);Gruß,
Beta-User
Problem wird sein das sendHeartbeat eigentlich eine Meldung an den Gateway ist und keine Meldung an FHEM. Ich nutze zu Verwaltung und auch zum OTA update das Programm MySController auch von tek. Da hat der Gateway kein "request heartbeat" wenn dort kein Sensors mit verbaut ist(wenn ich mich recht erinnere).
Leider kann ich da im Moment nichts aus eigener Erfahrung beisteuern.
Wie ich es bisher verstanden habe, ist das GW eigentlich "dumm" und tut nur, was ihm der Controller sagt (mal abgesehen von einer Art Sende-Puffer für derzeit schlafende Nodes und eben den Transfer in die Message-Struktur) bzw. "übersetzt" nur wieder rückwärts, was er von den Nodes erhält. Andererseits ist das GW neuerdings auch nur eine Node. Im Prinzip sollte daher ein Heartbeat-Reading - auch wenn es vom GW selbst kommt - problemlos an FHEM weiterzugeben sein. Man muß es halt entweder
- auch beim GW irgendwo in der loop() unterbringen und von der Seite her veranlassen oder
- seitens des Controllers den heartbeat vom GW anfordern
M.E. müsste dann noch in die ...DEVICE.pm (- auf beide Fälle hin - angepaßt werden (in dem internals-Teil wie battery), weil perl-seitig im Moment diese Art Info gar nicht vorgesehen ist (und von daher vermutlich ignoriert wird).
I_PING und I_PONG gibt es ja schon in den Internen Meldungen müsste das FHEM-Modul dann halt nur noch verwenden.
Fällt mir gerade mal auf, dem FHEM-Modul fehlt auch noch eine Timezone Korrektur. MySensors nutzt ja intern nur GTC.
Ich komme nicht voran...
Auf die Schnelle (musste meine Arduino-Installation zusätzlich auch noch neu aufbauen, da durch irgendeine Lib-Aktualisierung mit einmal kein flashen mehr möglich war) habe ich einen Sketch mit einem Dummy-Sensor aufgebaut. Definiert habe ich einen Temp-Sensor. Mein Ziel ist zunächst ganz einfach: Ausgabe irgend eines fixen Wertes - das reicht erst einmal.
Der Sketch läuft auch durch, aber ich bekomme weder eine Meldung im seriellen Monitor noch ein entsprechendes Reading in FHEM in der Gateway-Definition.
Ausgabe im ser. Monitor:
connected with WLAN4Me, channel 6
ip:192.168.0.33,mask:255.255.0.0,gw:192.168.0.1
.IP: 192.168.0.33
0;255;3;0;9;No registration required
0;255;3;0;9;Init complete, id=0, parent=0, distance=0, registration=1
Seconds since start: 0
pm open,type:2 0
Seconds since start: 11
Seconds since start: 21
Seconds since start: 32
Seconds since start: 42
Seconds since start: 53
0;255;3;0;9;TSP:SANCHK:OK
Seconds since start: 63
Seconds since start: 74
Seconds since start: 84
Seconds since start: 95
Seconds since start: 105
Seconds since start: 116
0;255;3;0;9;TSP:SANCHK:OK
Seconds since start: 126
list MySensorsGateway_7
Internals:
DEF 192.168.0.33:5003
DeviceName 192.168.0.33:5003
FD 126
NAME MySensorsGateway_7
NOTIFYDEV global
NR 880
NTFY_ORDER 50-MySensorsGateway_7
PARTIAL
STATE startup complete
TYPE MYSENSORS
ack 1
inclusion-mode 0
outstandingAck 0
version 2.0.0
Readings:
2016-11-08 21:10:38 connection startup complete
2016-11-08 21:10:38 state opened
Attributes:
first-sensorid 100
requestAck 1
room MySensors
stateFormat connection
verbose 2
Libraries:
Arduino: 1.6.11
MySensors: 2.0
ESP8266: 2.3.0
Hat einer eine Idee, wo mein Fehler liegen könnte?
LG
Holger
Hallo Omega,
an sich sieht das ja so aus, als würde bei FHEM was ankommen, die node aber gar nicht in die loop() gehen.
Ansätze:
vor die presentation() ein "before() {Serial.println("before done");}" - wenigstens hier sollte eine Ausgabe kommen
Den setup()-Aufruf hinter die presentation() verschieben (sollte eigentlich automatisch so abgearbeitet werden, kann aber auch nicht schaden), dort mal ein "Serial.println("setup done");" rein. Wenn das nicht klappt, ist irgendwas an der presentation() kaputt, evtl. dort noch mal den Test rein, ob er diese überhaupt aufruft?
Ansonsten fiel mir noch die 255.255.0.0 auf, sollte das nicht 255.255.255.0 sein?
Gruß,
Beta-User
Habe umgebaut. Ausgabe s. unten.
Der Loop funktioniert, alle 10 Sec. kommt eine simple Ausgabe der verstrichenen Sekunden seit dem Start. Nur die Ausgabe der Message mit der Temperatur will nicht. Und dadurch bekomme ich wohl auch kein passendes Reading in's GW.
Sind meine verwendeten Libraries richtig oder benötige ich irgend eine andere?
connected with WLAN4Me, channel 6
ip:192.168.0.33,mask:255.255.0.0,gw:192.168.0.1
.IP: 192.168.0.33
setup done
presentation done
0;255;3;0;9;No registration required
0;255;3;0;9;Init complete, id=0, parent=0, distance=0, registration=1
Seconds since start: 0
pm open,type:2 0
Seconds since start: 11
Seconds since start: 21
LG
Holger
schnell drüber geschaut finde soweit keine Fehler außer dem von Beta dann kann es nicht funken geht ins leere weil das Netzwerk nicht passt . Ich sehe auch kein "presentation" in der seriellen Ausgabe also wird auch nicht "presentiert". FHEM sollte mit einem neuen Node reagieren der, da GW die ID 0 bekommt. Dort tauchen die Werte auf.
Zitat von: Beta-User am 08 November 2016, 11:59:16
Warum tust Du Dich nicht mit Hexenmeister zusammen? M.E. gehört er zu den wirklichen MySensors-Heroes und hat dazu noch Ahnung vom ESP, die Aussichten wären also gut, dass ihr da zusammen was ans Laufen bringt!
;D Vielen Dank für die Blumen ;D
leider unverdient. Bin in diesem Jahr aufgrund der beruflichen und persönlichen Umstände kaum Zeit für mein Hobby finden können. Und dann noch mit dem Dachbodenausbau angefangen. ;D Bin daher nicht mehr ganz up-to-date, was MySensors angeht. Würde mich aber gern mittelfristig wieder einarbeiten und meine Nodes auf den aktuellen Stand bringen.
Btw. Habe wieder eine Charge Leer-PCBs für ESP-WLAN-MySensors-Gateway bekommen. Wenn also jemand Interesse hat - einfach melden.
Zitat von: Omega am 08 November 2016, 22:51:40
Habe umgebaut. Ausgabe s. unten.
Ok, das mit dem before()->presentation()->setup() funktioniert offensichtlich erst ab 2.0.1-beta; (@Hauswart: das erklärt das mit dem ID-Feld)
Dann kann es eingentlich nur der send()-Befehl sein. Mach dort mal testweise "" um die Temp-Angabe, also so:
send(msg.set("18.0",1));.
Das Aktualisieren der Web-Seite hast Du vermutlich ja (mehrfach) gemacht, sonst tauchen neue readings nicht auf...
Zitat von: hexenmeister am 09 November 2016, 00:53:32
leider unverdient.
Ist meine persönliche Meinung, aber
a) Dein Repo war für mich eine wahre Fundgrube, besser als viele Howto's
b) Dein GW-Sketch erfreut sich ziemlicher Beliebtheit, und ich habe schon Leute hier getroffen, die sehr skeptisch waren, als sie aufgefordert wurden, mal einen anderen als diesen Sketch zu nehmen (nämlich die "offiziellen" von MySensors bzw. die Beta-Version ;D).
c) Zähl doch mal durch, wieviele GW's und Platinen Du bisher in Umlauf gebracht hast ::). Das alleine dürfte wesentlich dazu beigetragen haben, dass sich einige mit dem Thema MySensors beschäftigt haben.
BTW: Die Dinger sehen wirklich gut aus! Wenn ich nicht noch (zu viele) ESP's hier rumliegen hätte, würde ich mich glatt für ein gelötetes (und geflashtes) bewerben (allerdings für Milight ;))...
Zitat von: Beta-User am 09 November 2016, 09:30:26
Ist meine persönliche Meinung, aber
Dann freue ich mich einfach, dass meine Arbeit hier helfen konnte :)
Insgesamt weiß ich es nicht genau, aber es müssten so ca. 250-300 Platienchen sein, die ich durch die halbe Europa verschickt habe ;D
Zitat von: Beta-User am 09 November 2016, 09:30:26
BTW: Die Dinger sehen wirklich gut aus! Wenn ich nicht noch (zu viele) ESP's hier rumliegen hätte, würde ich mich glatt für ein gelötetes (und geflashtes) bewerben (allerdings für Milight ;))...
Wenn Du noch ESP-12 liegen hast, kann ich Dir leere Platinen anbieten.
In der nächsten Zeit möchte ich auch mit MyLight-Bridge auf Basis meiner Gateway-Platinen experimentieren.
Hallo zusammen,
jetzt möchte ich doch nochmal auf das "startup complete"-Thema bei meinem seriellen GW zurückkommen und bitte - zwecks Verarbeitung im Wiki - um Rückmeldung:
- Ist es richtig, dass der reguläre Zustand eines GW "connected" sein sollte (und nicht "startup complete")?
- Gibt es andere, bei denen das GW nach dem flashen mit der aktuellen IDE (1.6.12) und der aktuellen Board-Definition nicht auf "connected" schaltet?
Wenn ja: Betrifft das 2.0.0 oder 2.0.1-beta? (Bei letzterer Version scheint das GW sogar häufiger reboots durchzuführen?)
- Nach "Downgrade" der Board-Definition auf -11 (oder niedriger): Inwieweit ist das Problem dadurch beseitigt?
Zum Hintergrund:
- die fragliche HW hatte ich seit Monaten problemlos in Betrieb, jüngst habe ich aber in kurzer Frist einige Änderungen vorgenommen/-nehmen müssen und kann manches daher nicht mehr exakt zurückverfolgen (es war wohl "urspünglich" ein 2.0.0-beta-GW, geflasht mit (ca.) der Arduino-IDE 1.6.7 und den damals aktuellen Boarddefinitionen)
- mit der aktuellen IDE und der Downgegradeten Board-Definition funktioniert das GW trotz des scheinbar inkorrekten Status ???.
@hexenmeister:
250-300 Stück: Wow! Und das zumindest in Teilen parallel zu den anderen Projekten, Respekt!
Was die Platine angeht: Ich habe die ESP-01-Variante und einige mit nach außen geführten PIN's, nicht die kompakte (Vorsichtsmaßnahme als lötmäßiger Grobmotoriker ::)).
Das mit der Nutzung für Milight (oder wohl besser Wifilight?) scheint kein großes Ding zu sein, jedenfalls nach den Berichten von Schka17 (https://forum.fhem.de/index.php/topic,58742.0.html). Da ist eher die Frage spannend, wie man die Info über Steuervorgänge außerhalb von FHEM (am liebsten ohne MQTT) innerhalb FHEM auswertet und die readings kohärent hält...
@Beta-User
ich nutze hier die aktuellste Arduino Version mit aktuellsten Libs ohne Downgrade aber MySensors Stabel und dem original Sketch(mit Anpassungen). Der GW hat in FHEM nur zwei readings :
Connection und state
Connection hat immer "startup complet"
State wechselt zwischen conectet, disconected und inizialised.
In MYSControl bekomme ich auch nur "startup complet" plus die Präsentation Meldung vom GW. Das reboot Problem ist wohl bekannt soll aber angeblich an schwacher Versorgung liegen der ESP ist da wohl empfindlich. Ansonsten sollte man den ESP mal vollständig löschen (http://s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/131-loeschen-des-gesamten-flashspeichers) und neu flashen.
@Hexenmeister
was soll denn so ein GW Board mit Bauteilen kosten ? Mein GW hier ist alles nur Luftverdrahtung ;D will das mal ändern .
@kleinerDrache
Hattest Du nicht ein WLAN-GW mit ESP? Oder nutzt Du gerade auch ein serielles GW (also mit Arduino).
Was bedeutet
Zitat von: kleinerDrache am 10 November 2016, 09:31:31
State wechselt zwischen conectet, disconected und inizialised.
Passiert das von alleine oder aus welchem Anlaß?
Zur Erläuterung: Mein GW hatte mit der aktuellen Board-Definition (.14) -soweit ich das noch im Kopf habe - den Status "startup complete" immer wieder erneuert (Wechsel zu roter Darstellung nach Refresh bzw. update des Aktualisierungszeitpunkts des readings), was recht eindeutig darauf zurückzuführen ist, dass der Arduino schlicht immer wieder neu gebootet haben dürfte. Entsprechende Meldungen gab es auch bei MySensors und oben von SvenJust (#msg516966) und es läge nahe, dass Markus80 genau dasselbe Problem hat.
Im Moment passiert das bei mir nur, wenn ich auf den "connect"-Button klicke... (Aber wie erwähnt: das GW empfängt trotzdem fleißig Daten ???)
@Markus80: Könntest Du das mit dem Downgrade der Board-Def. mal testen?
Danke und Gruß
Beta-User
Stimmt Ihr habt ja serielle GW`s sorry war mir entfallen
Zitat von: kleinerDrache am 10 November 2016, 11:17:05
Stimmt Ihr habt ja serielle GW`s sorry war mir entfallen
Na ja, ich hätte es unterstreichen können. Trotzdem erscheint ist es interessant, dass das GW nicht "conneted" meldet. Könntest Du daher evtl. meine Frage von Vorhin (was bedeutet...) beantworten?
Und:
Können einige, die ein älteres GW nutzen (also auch 1.5.4 und 2.0.0, möglichst geflasht mit IDE <1.6.8, egal ob jetzt WLAN, seriell oder LAN) mal mitteilen, was denn jetzt der "Soll"-Zustand für FHEM ist. "Connected" oder "startup complete"? Nicht, dass ich da schlicht an der falschen Stelle suche :-\. Leider werde ich aus dem perl-Text des Moduls nicht so recht schlau...
Zitat von: Beta-User am 10 November 2016, 12:32:01
Können einige, die ein älteres GW nutzen (also auch 1.5.4 und 2.0.0, möglichst geflasht mit IDE <1.6.8, egal ob jetzt WLAN, seriell oder LAN) mal mitteilen, was denn jetzt der "Soll"-Zustand für FHEM ist. "Connected" oder "startup complete"?
Bei mit (alles noch 1.5.x) steht auch immer nur "startup complete".
Hallo zusammen,
ich hatte Gestern zum Test ein GatewayW5100 (aktuelle- Beta) getestet, der Status war "conneted", leider wurden keine Readings angelgt.
Weiter laufen zwei ESP-GW einmal Version 2.0.0-Beta und 1.5, ist aber schon etwas her. Beide laufen mit Staus "startup complete". Ein reappeared der GW kommt aber immer wieder mal im logfile. Da ich immer wieder Probleme mit dem Mysensors-Modul hatte bin ich auf MQTT und das FHEM - Modul MQTT_DEVICE umgestiegen, da habe ich keine Probleme. Ich Würde mich freuen wenn die MySensors - Module wieder aktuell sind.
Gibt es eine neuere Version der MYSENSOR - Module zum runterladen ?
Zitat von: kleinerDrache am 10 November 2016, 09:31:31
was soll denn so ein GW Board mit Bauteilen kosten ? Mein GW hier ist alles nur Luftverdrahtung ;D will das mal ändern .
Leere PCBs habe ich für je 2 Euro verkauft (habe gerade wieder neue Charge bekommen, allerdings müsste ich noch eine aufbauen und testen, da zuletzt leichte Änderungen im Layout eingepflegt).
Bausätze verkaufe ich eigentlich nicht mehr, das Sortieren/Beschriften der Teile ist mir zu zeitaufwendig.
Für jemanden, wer vernünftige Software dazu entwickelt, mit WebConfig und OTA, mache ich natürlich eine Ausnahme ;D
Gib mir per PM Deine Adresse, ich sende Dir ein Bausatz zu. Habe allerdings gerade keine ESP-12 mehr. Hast Du welche liegen, bzw. kannst selbst eine besorgen?
@all: Danke für die Rückmeldungen bis dato, vielleicht kommen ja noch ein paar dazu.
Zitat von: Peter_64 am 10 November 2016, 13:22:37
ich hatte Gestern zum Test ein GatewayW5100 (aktuelle- Beta) getestet, der Status war "conneted", leider wurden keine Readings angelgt.
Hast Du noch die Info, wie Du den Arduino geflasht hast (Arduino-IDE? Welche Version?)
Könntest Du ggf. mal die Board-Definition <=1.6.11 verwenden und dann das Ergebnis melden?
Zitat von: Peter_64 am 10 November 2016, 13:22:37
Weiter laufen zwei ESP-GW einmal Version 2.0.0-Beta und 1.5, ist aber schon etwas her. Beide laufen mit Staus "startup complete". Ein reappeared der GW kommt aber immer wieder mal im logfile.
Würdest Du das Phänomen eher auf das Modul, den MySensors-code oder doch auf Reboots der ESP's zurückführen? Bei dem ESP-Quellcode gab es nach meinem Kenntnisstand im letzten Jahr noch erhebliche Probleme mit den timings, was u.A. auch zu seltsamen readings bei mehreren Nodes im Netzwerk führte :(.
Zitat von: Peter_64 am 10 November 2016, 13:22:37
Da ich immer wieder Probleme mit dem Mysensors-Modul hatte...
Kannst Du das etwas näher beschreiben? Es ist das nach meiner erste Mal, dass jemand grundsätzliche Kritik an den
Modulen äußert. Jedenfalls bei mir waren die beiden betreffenden *.pm's über Monate problemlos im Einsatz (ich habe aber auch nicht intensiv nach Fehlern gesucht!).
Verbesserungsbedarf an den Modulen sehe ich im Moment vielleicht an zwei-drei Ecken:
1. Einige der Sensortypen sind noch nicht hinreichend beschrieben ([receives], [sends]) und es gibt noch nicht alle Sensortypen, die zwischenzeitlich Eingang bei MySensors.org gefunden haben. Beides läßt sich aber nachrüsten oder umgehen (einfach anderen Typ nehmen, z.B. Wasser statt Gas oder die entsprechenden Korrekturen in die .pm einpflegen).
2. Neue Funktionen (heartbeat() und asynchrones Senden an die Nodes) werden noch nicht unterstützt
3. OTA
Das ist aber alles nicht so tragisch, dass einen das von MySensors abhält, oder?
@Beta-User
Mein Gateway zeigt ebenfalls STATE "startup complete" und state "opened".
Geflashed mit IDE 1.6.12 und MySensors 2.0
Probleme mit Reboots des Gateways habe ich keine.
btw. habe ich mal mit den Channels ein bisschen gespielt und interessanter weise,
bekomme ich bei mir auf Channel 0 und 1 keinerlei Verbindung.
Würde jetzt gerne noch das signing mit rein nehmen, aber das hab ich noch nicht so ganz geschnallt :D
Viele Grüße,
Lars
zu
Kannst Du das etwas näher beschreiben? Es ist das nach meiner erste Mal, dass jemand grundsätzliche Kritik an den Modulen äußert. Jedenfalls bei mir waren die beiden betreffenden *.pm's über Monate problemlos im Einsatz (ich habe aber auch nicht intensiv nach Fehlern gesucht!).
Das sollte wirklich keine Kritik für das sehr gute Modul sein :-) Ich hatte damals Relais geschalten, die gingen eine Zeit lang sehr gut, und dann aus dem nichts Probleme. Für mich als reiner Anwender nicht erklärlich. Bei Sensoren hatte ich keine Probleme. Aber wenn Zeit ist werde ich mich wieder ran tasten...
Danke für Eure Arbeit :-)
@ all:
Nochmal Danke, ich hätte aber vielleicht noch ausdrücklich klarstellen sollen, dass mich die Art des jeweiligen GW zu den ganzen Infos auch interessiert (ist aber bei den meisten jetzt klar.
Für Neue: "Standardstatus", GW-Art, MySensors-Version, IDE-Version (bzw. andere IDE)
Zitat von: Feuerpfeil am 10 November 2016, 14:18:02
btw. habe ich mal mit den Channels ein bisschen gespielt und interessanter weise,
bekomme ich bei mir auf Channel 0 und 1 keinerlei Verbindung.
Würde jetzt gerne noch das signing mit rein nehmen, aber das hab ich noch nicht so ganz geschnallt :D
1. Mit der Channel-Nummer nimmt die Reichweite eher ab. >76 (Standard) soll besser sein, aber rechtliche Obergrenze in D (83?) beachten!
Vermutlich hast Du aber schlicht eine Überlagerung mit einer WLAN-Frequenz eines Routers in der Nähe und solltest einen gewissen Abstand einhalten ;).
2. Signing kenne ich bislang nicht; einige spezielle ESP-Module haben einen entsprechenden Chip bereits verbaut, das muß man im Sketch aktivieren; ansonsten in Software (wobei es eine der an der Kommunikation beteiligten Nodes ausdrücklich fordern muß und ein Mischbetrieb SW/HW funktionieren soll).
Jedenfalls früher gab es da bei Mysensors.org eine sehr anschauliche Darstellung dieser Geschichte und der Frage, was es an Sicherheitsgewinn bringt (ok, ist Ansichtssache, aber aus meiner Perspektive). Das ist übrigens auch sehr anschaulich, das Angriffsszenarios wie man-in-the-middle-Attacken usw. angeht =>
nicht nur für MySensors interessant, um die Prinzipien zu verstehen.
Hier der aktuelle Link (https://www.mysensors.org/about/signing), ist wohl im wesentlichen noch so ;)
@Beta-User
ESP-WLAN Gateway
habs gerade nochmal getestet:
Reading connection: hat bei mir IMMER den Wert "startup complete" selbst wenn ich den GW komplett abschalte
Reading state: bei anlegen der Devices kommt "initialized" und dann nur noch entweder "opened" oder "disconnected" (sorry den Wert"connected" gibet garnicht)
weitere Readings hat das GW nicht.
Ich habe dann noch per StateFormat den state auf in den Device verlegt weil da sonst das Reading connection angezeigt wird (ziemlich nutzlos da es sich nie ändert)
@Feuerpfeil
Habe bei mir auch den Channel vom NRF geändert (auf 0) und erziele damit weit bessere Verbindung(weniger Abbrüche höhere Reichweite) als mit dem Standard (hab aber auch hier ca 10 WLAN Netze die mir da reinhämmern). Hast du bei dir nur am GW den Channel geändert oder auch in den Nodes ? Kondensator direkt am NRF wegen Spannung stützen ?
Wegen signing kann ich nur sagen: soft signing ist mist, sorgt für ziemlich heftige Verzögerungen, von FHEM meinem RGB Node gesagt bitte Rot bis das da ankommt dauert es schon mal 2-3 Sekunden.
Hardware hab ich mangels Masse (hab keinen Chip) nicht ausprobiert.
Zitat von: kleinerDrache am 10 November 2016, 17:22:05
@Feuerpfeil
Habe bei mir auch den Channel vom NRF geändert (auf 0) und erziele damit weit bessere Verbindung(weniger Abbrüche höhere Reichweite) als mit dem Standard (hab aber auch hier ca 10 WLAN Netze die mir da reinhämmern). Hast du bei dir nur am GW den Channel geändert oder auch in den Nodes ? Kondensator direkt am NRF wegen Spannung stützen ?
Wegen signing kann ich nur sagen: soft signing ist mist, sorgt für ziemlich heftige Verzögerungen, von FHEM meinem RGB Node gesagt bitte Rot bis das da ankommt dauert es schon mal 2-3 Sekunden.
Hardware hab ich mangels Masse (hab keinen Chip) nicht ausprobiert.
Die Lage mit den WLan Netzen sieht bei mir leider nicht anders aus. Aktuell sind es neun.
Werde im Januar umziehen. Bin gespannt wie es dann dort sein wird.
Ich hatte den Channel auf dem Gateway und auf dem node geändert.
Bin jetzt auf Channel 83 (RF24 channel 84). Das funktioniert so weit und so bin ich dann auch zumindest vom "Standard" Channel runter.
Am Gateway hab ich einen 10uf Kondensator drauf. Da ich als Node im Moment leider nur 5V Arduinos habe, habe ich am nrf24l01 einen fertigen Adapter vom Ali
https://www.aliexpress.com/item/New-Socket-Adapter-plate-Board-for-8Pin-NRF24L01-Wireless-Transceive-module-51/32652342305.html (https://www.aliexpress.com/item/New-Socket-Adapter-plate-Board-for-8Pin-NRF24L01-Wireless-Transceive-module-51/32652342305.html)
Hab das mit dem signing jetzt auch so weit verstanden. ;D
Bei dem umfangreichen Artikel, habe ich das Wesentlich einfach übersehen.
Danke jedenfalls für den Tipp. Dann werde ich softsigning gar nicht erst ausprobieren.
Wenn meine 3V Arduinos da sind und zwei /drei nodes stabil laufen, werde ich mal welche von den ATSHAs bestellen und testen.
OTA würde mich dann ebenfalls interessieren, aber wie ich das gelesen habe, scheint die Beschaffung der Chips nicht ganz so einfach zu sein.
Ich verwende hier Nanos , und nehme nur für power 3,3 V. Die Daten Pins des NRF sind 5V tolerant (hier ist mir in 1 Jahr noch kein NRF abgeraucht). Chip ?? Für OTA ?? Nimm doch den MYSBootloader der braucht keinen extra Chip. Einziger unterschied mittlerweile zum anderen OTA-Bootloader : wärend des Updates kommen keine Messwerte und wenn die neue Firmware fehlerhaft ist musste unter Umständen manuell flashen weil der Sensor nicht mehr reagiert.
Die ATSHA würde ich auch nur verwenden wenn es um kritische Übertragungen geht (Türöffner, Fenster kontakte usw.) Mischbetrieb ist da problemlos möglich. Oder du nimmst halt den Sensbender da ist sowohl ein ATSHA als auch extra Speicher drauf.
Zitat von: kleinerDrache am 30 Oktober 2016, 17:14:07
Hm hatte damit auch schon mal Probleme ein ändern der Sende Channels hat
1. Die reichweite gewaltig erhöht und
2. die abbrüche waren auch passe
Standardmässig läuft MySensors auf Channel 76 also 2476 Mhz. Da kommt mann schonmal mit älteren Wlan Geräten in Konflikt.
Ich gehe mal davon aus, dass man eine Kanaländerung für alle Geräte (Gateway und Sensoren) machen muss, oder? Insofern wäre da OTA recht geschickt ;)
Habe gerade festgestellt, dass bei mir WLAN Kanal 11 durch die Nachbarn stark belegt ist, insofern ist NRF Kanal 76 vielleicht suboptimal ???
Gruß PeMue
Stimmt aber Obacht im Momment funkt nach Änderung des Channels OTA "NICHT" warte da immer noch auf ne Meldung von dem Bootlader Bauer
Hallo zusammen,
Anmerkungen zu den diversen Dingen:
@PeMue
Das mit dem battery level als Voltage ist evtl. einfach zu lösen:
Versuch mal, das Mapping manuell zu machen wie im nachstehenden Beispiel für IR_Send; dabei müßte es voltagex heißen mit x=ChildID, unter der Du die battery-Voltage verschickst.
attr MYSENSOR_99 mapReading_ir_send3 3 ir_send)Anm.: (wenn "0", dann würde das wohl mapReading_ir_send 0 ir_send lauten).
An sich ist die Lage etwas anders als der Standardfall, weil battery ein internes Reading ist, das seitens MYSENSORS_DEVICE.pm speziell behandelt wird und Voltage "eigentlich" zum Sensor-Typ Multimeter gehört (damit wäre die Alternative, ein weiteres Child vom Typ Multimeter zu präsentieren und darunter die Voltage zu versenden; das wäre m.E. aber die unsauberere). Die Unsicherheit, ob das überhaupt funktioniert kommt übrigens daher, dass seitens MySensors nicht vorgesehen ist, battery als Voltage-Wert darzustellen (jedenfalls lt. Serial API) ;).
Zitat von: kleinerDrache am 13 November 2016, 21:44:18
Stimmt aber Obacht im Momment funkt nach Änderung des Channels OTA "NICHT" warte da immer noch auf ne Meldung von dem Bootlader Bauer
Zur Erläuterung: in dem betr. Forumsbeitrag bei Mysensors (https://forum.mysensors.org/topic/4991/mysbootloader-1-3pre2-testing/19) ist davon die Rede, dass
in dem Bootloader-code der Channel für Updates fest auf 76 eingestellt ist. Das macht m.E. mit gewissen Einschränkungen sogar Sinn, da man so die Nodes erreicht, selbst wenn man den für die FW urspünglich mal verwendeten Channel vergessen haben sollte, aber noch ein GW mit dem richtigen Channel hat 8).
[Test- und Spekulationsmodus]
Folgendes Setup könnte evtl. aber gehen und uns sogar für die OTA-Funktionalität aus FHEM heraus weiterbringen:
1. GW auf Channel 76 an dem Rechner, von dem aus das Update (=*.hex?) effektiv übertragen werden soll
2. GW mit dem aktuellen Channel der Node zum Start des OTA-Vorgangs
3. GW, das auf dem "neuen" Channel läuft (braucht man nur für den Fall, dass das ein anderer ist als im 2. GW bzw. Channel 76)
Dann wäre interessant,
- wie lange die Node im OTA-Boot-Modus verbleibt und
- was der Befehl für "boot to OTA-Bootloader" wäre. Da die Nodes nach einem "Reboot-Befehl" seitens FHEM nicht mehr zu erreichen sind, könnte es sogar sein, dass das die Initiierung des OTA-Modus von FHEM aus gestartet werden könnte (bzw. schon wird).
Wäre der Status "erwarte update" "ewig" (bis zu einem Neustart aus anderen Gründen), könnte man dann mit dem 2. Rechner/GW den eigentlichen Upload-Befehl starten.
Testfelder wären:
- Klappt das mit dem Update über den MYSController, wenn dieser den OTA-Modus nicht selbst initialisiert. Er "sieht" die Node ja nicht, solange sie in einem anderen Netz (=channel) ist. Ein weiteres Absetzen des Befehls "Reboot to OTA" seitens des Tools würde vielleicht nicht schaden, kann aber evtl. nicht sauber ausgeführt werden, wenn das Tool diesen gar nicht mehr ausführen kann, wenn die Node bereits im OTA-Modus ist.
- Handelt es sich bei dem OTA-update nur um eine Art seriellen Kopierbefehls, könnte man das update evtl. auch (ähnlich der HM-updates?) mit einem Konsolenbefehl ohne das Windoof-Tool durchführen, man müßte nur das richtige Device (channel76) als I/O auswählen und natürlich die Node benennen, an die es (das Update) gehen soll.
[/Test- und Spekulationsmodus]
Sollten wir die OTA betreffenden Fragen eigentlich in den Howto-Thread auslagern? Ist sehr speziell (wobei es bei diesem Thread hier eingentlich auch nicht mehr drauf ankommt ;D)
zu OTA: wenn ich das richtig verstehe geht jeder Node nach dem Reboot erstmal in Update Bereitschaft ,das sieht man schön im MYScontroller der immer 4 Meldungen betreff Firmware bekommt.
Wird in der Zeit mit einer neuen Firmware geantwortet startet die Übertragung derselben und nach Erfolg und Abgleich der CRC wird Resetet. dann beginnt das Spiel von vorne bis Firmware Node = Firmware die der Gateway anbietet. Ergo die Nodes Initialisieren das Update NICHT der GATEWAY der schickt nur den Resetbefehl.
Da aber der NRF immer nur einen Channel zur selben Zeit benutzen kann funkt das OTA mit geändertem Channel nicht mehr weil der NRF Channel im Bootloader Hardcodiert ist und das ist 76. Hast du jetzt deinen Gateway auf z.B. 0 geändert kann der MYScontroller nicht mehr auf die Anfragen vom Node reagieren weil halt falscher Channel.
zu Battery Voltage: Schau in den Sketch von mir zum Bewegungsmelder der überträgt sowohl Prozent als auch Voltage (wenn der Spannungsteiler stimmt sogar richtig). Mit dem Internen Voltage Meter von Atmega sollte auch gehen aber hab ich nicht probiert. Auch das Mapping sollte automatisch gehen. In den Attributen zwar wild durcheinander aber in den Readings tauchen nur Werte auf wo auch was drin ist. Eventuell müssen da noch die geänderten MySensors Dateien in FHEM kopiert werden da ich nicht weiß ob das schon automatisch per update passiert.
Hallo kleinerDrache,
ich verstehe Deinen Post nicht so recht. Hast Du jetzt ein oder 2 GW's im Einsatz? Dass es mit nur einem nicht gehen kann, ist klar. Man braucht das eine, um auf dem aktuellen Channel mitzuteilen, dass etwas übertagen werden soll und das andere, um die Firmware tatsächlich auf Channel 76 zu übertragen. Da die Node offensichtlich weiter funktioniert, wenn das update wg. Channel-Wechsels abgebrochen wird, ist anzunehmen, dass die FW gar nicht angefaßt wird, bevor nicht auf Channel 76 die FW-Daten rübergeschaufelt werden.
Daher die Frage vorhin:
- wie lange bleibt die Node updatebereit auf Channel 76, wenn sie in den OTA-Mode geschickt wird und
- reicht es aus, wenn man in FHEMWEB den "reboot"-Button drückt, um sie in den OTA-Mode zu versetzen?
(OK, es würde evtl. auch mit nur einem GW gehen, wenn das GW wüßte, dass es den Kanal vorübergehend auf 76 wechseln soll, sobald ein Update einer anderen Node angesagt ist; diese Funktionalität ist aber offensichtlich nicht implementiert).
Wenn Du es also bisher mit einem GW versucht hast: Hast Du ein anderes, 2. GW, das Du auf Channel 76 flashen kannst?
Wenn ich es richtig verstanden habe, hast Du einen FHEM-PI und ein Laptop mit dem MYSController.
Wenn ja: Gib doch bitte für den Laptop dieses 2. GW mit Channel 76 als GW vor. Kannst Du dann von FHEMWEB aus über das 1. GW (Channel 0) die Node in den reboot schicken und versuchen, dann das update vom Laptop aus draufbügeln oder erlaubt MYSController evtl. sogar die Verwendung von 2 I/O-s zu diesem Zweck?
Zu battery voltage: habe zwar nur kurz gesucht, bin aber nicht drauf gekommen, welchen Sketch Du meinst. Kannst Du evtl. den Link nochmal posten oder die ersten paar Zeilen Code (relevante Defines, myMessages und die presentation()); Du tätest jemandem anderen einen großen Gefallen :).
Oder hast Du etwas an der MYSENSORS_DEVICE.pm geändert?
Zitat von: Beta-User am 14 November 2016, 16:21:03
Zu battery voltage: habe zwar nur kurz gesucht, bin aber nicht drauf gekommen, welchen Sketch Du meinst. Kannst Du evtl. den Link nochmal posten oder die ersten paar Zeilen Code (relevante Defines, myMessages und die presentation()); Du tätest jemandem anderen einen großen Gefallen
Das müsste der aus diesem Post sein: https://forum.fhem.de/index.php/topic,26807.msg512553.html#msg512553
genau der
Edit: hmpf wenn man nicht genau liest *gg*
Nein ich verwende im Moment nur einen Gateway und zwar Einen Wlan-Gateway auf ESP-Basis und update im Moment nicht OTA (Channel geändert auf 0). Ich warte auf die Sourcen Von Teek um mir selber den Bootloader zu kompilieren der dann auch auf Channel 0 lauscht.
Die Nodes müssen ja erstmal mit dem MYSBootloader bespielt werden der Reset funktioniert glaub ich auch NUR mit diesem Bootloader. MYSController läuft bei mir auf Linux unter Wine. Ich glaube es geht immer nur ein Gateway in dem Programm.
Nach dem Reset kommen 4 Meldungen im MYSController an die glaube ich auf "Inter 'configure Firmware'" lauten und nach der im MYSController hinterlegten Firmwareversion fragen. diese Sequenz dauert ca 5-10 Sekunden. Mit zwei Gateways hab ich noch nicht probiert.
Edit2: Sorry wenn ich was konfus schreibe hab hier im mom ne menge zu tun *gg* FHEM retten, MySensors weiter machen, Rechner neu machen, 3D-Drucker rumbasteln also jede menge Baustellen ;)
@PeMue
Danke, das war er; da steht:
present(CHILD_ID_BATT, S_MULTIMETER);Dass es damit geht, ist klar.
Zitat von: Beta-User am 14 November 2016, 12:45:08
und Voltage "eigentlich" zum Sensor-Typ Multimeter gehört (damit wäre die Alternative, ein weiteres Child vom Typ Multimeter zu präsentieren und darunter die Voltage zu versenden; das wäre m.E. aber die unsauberere).
Versuche es doch bitte erst mit der manuellen Vergabe des attr, sonst bekommst Du auch die anderen Multimeter-Readings per Automatik.
Zitat von: kleinerDrache am 14 November 2016, 16:44:19
Edit: hmpf wenn man nicht genau liest *gg*
Kein Problem, geht uns allen hin und wieder so ::) ::). Und dass ich grade auf der Suche nach diesen ganzen Feinheiten bin, macht die Sache nicht einfacher 8).
Zitat von: kleinerDrache am 14 November 2016, 16:44:19
Ich warte auf die Sourcen Von Teek um mir selber den Bootloader zu kompilieren der dann auch auf Channel 0 lauscht.
Es gibt sourcen (auch dev.) auf Mysensors@github, ob die allerdings sooooo aktuell sind, kann ich nicht sagen (2 Monate+). M.E. ist ein entsprechend geänderter Bootloader-Channel aber nur eine halbe Lösung; wir wären alle mit einer generischen Lösung besser bedient, weil diese immer funktionieren würde (jedenfalls wenn nicht gerade der Channel 76 das funktechnische Hauptproblem ist).
Klasse wäre eine automatische GW-Umschaltung auf Channel 76 für eine bestimmte Zeit, um der Node Gelegenheit zu geben, das update abzuholen.
Wenn es "hilfsweise" mit einem 2.GW im Parallel-Betrieb ginge, wäre das auch ok.
Da Du (bis auf das 2. GW) alles bereits hast (und mir damit um einiges voraus bist): könntest Du nicht einfach den beschriebenen Test mit dem 2. GW machen ;); ein serielles ist ja schnell zusammengestöpselt, wenn man die Bauteile hat :). Und für das Update kannst Du ja direkt neben die "Ziel-Node" stehen, dann ist Funkreichweite auf Channel 76 vermutlich kein Störfaktor....
Danach darfst Du das auf Kanal 0 umgeflashte serielle GW gerne als Standard-GW für FHEM nutzen, ich laß Dich in Ruhe und Du kannst Dich weiter Deinen anderen Baustellen widmen 8).
klar kann ich machen wenn endlich meine Bauteile aus China da sind *gg* hab nämlich keine NRF's mehr. Müssten aber morgen oder übermorgen ankommen hoffe die sind dann dabei *lach*
Ansonsten melden, ich habe ein paar über...
Auch mit ext-Antenne.
der mit externer Antenne "NUR" Antenne oder das erweiterte Modul ? Hab vergessen mir mal so ein Ding zu bestellen für meinen Gateway.
Zitat von: kleinerDrache am 12 November 2016, 12:28:37
Ich verwende hier Nanos , und nehme nur für power 3,3 V. Die Daten Pins des NRF sind 5V tolerant (hier ist mir in 1 Jahr noch kein NRF abgeraucht). Chip ?? Für OTA ?? Nimm doch den MYSBootloader der braucht keinen extra Chip. Einziger unterschied mittlerweile zum anderen OTA-Bootloader : wärend des Updates kommen keine Messwerte und wenn die neue Firmware fehlerhaft ist musste unter Umständen manuell flashen weil der Sensor nicht mehr reagiert.
Die ATSHA würde ich auch nur verwenden wenn es um kritische Übertragungen geht (Türöffner, Fenster kontakte usw.) Mischbetrieb ist da problemlos möglich. Oder du nimmst halt den Sensbender da ist sowohl ein ATSHA als auch extra Speicher drauf.
Hab heute mal mit dem MySBootloader herumgespielt. Leider wieder ohne großen Erfolg.
Zum einen, kann ich den Pro Mini mit dem Bootloader nicht mehr seriell flashen, (bekomme dann immer eine Out of Sync Fehlermeldung von der IDE) und zum anderen kann die OTA Funktion nicht initialisiert werden.
Ich sehe dann im debug monitor bei Firmware ein fail.
Das ist mittlerweile ein bissl frustrierend.
Bin schon am überlegen, ein komplettes How-To zu schreiben, wenn irgendwann mal alles läuft.
Zitat von: Beta-User am 14 November 2016, 12:45:08
@PeMue
Das mit dem battery level als Voltage ist evtl. einfach zu lösen:
Versuch mal, das Mapping manuell zu machen wie im nachstehenden Beispiel für IR_Send; dabei müßte es voltagex heißen mit x=ChildID, unter der Du die battery-Voltage verschickst.
attr MYSENSOR_99 mapReading_ir_send3 3 ir_send
So, ich habe jetzt alles durch, aber die voltage wird im Sketch mit der Library v2.0 nicht angezeigt. Immer beim Einschalten macht fhem ein zusätzliches Attribung:
mapReading_value13 3 value1, da kommen aber keine Werte in
value1 an.
Vielleicht werfe ich den kompletten Sensor mal aus fhem raus und lasse ihn neu anlegen ...
Gruß PeMue
@Feuerpfeil
So ein Tutorial (https://forum.fhem.de/index.php/topic,59388.msg507677.html#msg507677) gibt es schon *gg* .
Ich denke Du hast den Bootloader aus der Git genommen. Dieser ist schon etwas älter, mit dem aus meinem Tutorial sollte sowohl seriell als auch per OTA gehen. Aber Achtung hab schon festgestellt bei dem 1MHz Bootloader kann es passieren das man den Brenner in Arduino zwischen dem AVRISP und dem AVRISP MK2 wechseln muss. der Bootloader ist halt immer noch Beta.
Zitat von: PeMue am 15 November 2016, 21:09:01
So, ich habe jetzt alles durch, aber die voltage wird im Sketch mit der Library v2.0 nicht angezeigt. Immer beim Einschalten macht fhem ein zusätzliches Attribung:
mapReading_value13 3 value1, da kommen aber keine Werte in value1 an.
Vielleicht werfe ich den kompletten Sensor mal aus fhem raus und lasse ihn neu anlegen ...
Gruß PeMue
Hallo PeMue,
das ist ziemlich seltsam. Der Sketch, den Du am 30.10. auszugsweise gepostet hast, sollte - unabhängig von der verwendeten lib-Version - wirklich funktionieren, vor allem, wenn Multimeter präsentiert wird...
Das vorläufig letzte, das mir nach Analyse des Codes als mögliche Ursache erscheint:
Es hängt evtl. an der "3" in Deinem Sendekommando:
send(msgBatt.set(send_voltage,3));Das ist bei kleinerDrache ein
send(msgBatt.set(batteryV,2));Vielleicht kannst Du einen Test mit "send_voltage,2" machen? Leider habe ich keine Ahnung, was der Parameter an der Stelle zu bedeuten hat, es ist jedenfalls nicht die ChildID; die ist ja in der "msgBatt"-Definition bereits drin und wäre auch beim Sketch von kleinerDrache nicht "2", sondern "0".
Wenn's nicht klappt: Hast Du noch einen Link zu dem Originalen Sketch, auf den Du Dich beziehst?
wenn ich die Doku gerade richtig im Kopf habe kannst du mit dem letzten Wert die Dezimalstellen der gesendeten Werte festlegen.
Hallo zusammen,
Zitat von: Beta-User am 16 November 2016, 09:58:20
Vielleicht kannst Du einen Test mit "send_voltage,2" machen?
https://www.mysensors.org/download/sensor_api_20
ZitatSending data
You can send data to the controller or some other sensor by using the send(msg) method.
bool send(MyMessage &msg, bool ack);
msg - The message you want to send. See MyMessage for details.
ack - Set this to true if you want destination node to send ack back to this node. Default is not to request any ack.
Meine Interpretation: alles <>0 fordert einen ACK an, bei =0 wird kein ACK angefordert. Sprich: zum probieren entweder 0 bzw. 2 oder 3 müsste dasselbe Resultat zeigen.
Zitat von: Beta-User am 16 November 2016, 09:58:20
Wenn's nicht klappt: Hast Du noch einen Link zu dem Originalen Sketch, auf den Du Dich beziehst?
Ja, suche ich raus. Ist aber auch in meinem Sketch dokumentiert. Bin aber gerade nicht am Rechner ...
Gruß PeMue
Kurzfassung, muß dringend weg:
Im Moment glaube ich nicht mehr so recht, dass es am Sketch liegt. Vorhin hat noch jemand berichtet, er würde (aber nur mit FHEM als Controller) Nachrichten verlieren.
Auch eine meiner Nodes meldet seltsame Meßwerte, bisher dachte ich, das liegt an der Stromversorgung; es handelt sich um die letzten beiden erwarteten Werte.
Als Test würde ich jetzt erst mal alle zu versendenen Messages zeitlich entzerren ("wait(200)" oder so) bei presentation() der ChildIDs und zwischen Sendebefehlen.
@PeMue: Bitte um Infos zur Infrastruktur und IDE/Boarddef etc...
Zitat
https://www.mysensors.org/download/sensor_api_20
Zitat
Sending data
You can send data to the controller or some other sensor by using the send(msg) method.
Code: [Auswählen]
bool send(MyMessage &msg, bool ack);
msg - The message you want to send. See MyMessage for details.
ack - Set this to true if you want destination node to send ack back to this node. Default is not to request any ack.
Meine Interpretation: alles <>0 fordert einen ACK an, bei =0 wird kein ACK angefordert. Sprich: zum probieren entweder 0 bzw. 2 oder 3 müsste dasselbe Resultat zeigen.
Schau mal etwas weiter unten, da steht noch wie der Pointer "MyMessage &msg" aufgebaut sein kann. Heisst je nach gesendetem Wert kann da auch noch eine weitere Option dazu kommen deswegen lautet die richtige definition des sends:
send(msgBatt.set(batteryV,2),true);
um ein ACK anzufordern. In diesem Fall steht das ",2" für die Anzahl der Dezimalstellen. Wie genau das Funktioniert ist in der MyMessages.h hinterlegt. Der Wert für ACK kann eh nur zwei Werte annehmen ist ja ein BOOL.
Zitat von: Beta-User am 17 November 2016, 18:02:21
@PeMue: Bitte um Infos zur Infrastruktur und IDE/Boarddef etc...
IDE: Arduino 1.6.5R5
Boarddefinition: Sensebender Micro (https://raw.githubusercontent.com/mysensors/ArduinoBoards/master/package_mysensors.org_index.json), wo das installiert wird, habe ich noch nicht herausgefunden
Sketch Ursprung: https://raw.githubusercontent.com/mysensors/SensebenderMicro/master/Arduino/SensebenderMicro/SensebenderMicro.ino
Sketch: siehe Anhang
Ich werde mittlerweile immer ratloser ???
Bei einem der beiden sind die Batterien auch immer ruck-zuck leer. Ich vermute, ich habe da einen fake NRF24L01+ >:(
Gruß PeMue
Edit1:
Ok, habe den Pfad gefunden: ..\portable\packages\MySensors
menu.cpu=Processor
######################################
## Sensebender Micro
MysensorsMicro.name=Sensebender Micro
MysensorsMicro.upload.tool=arduino:avrdude
MysensorsMicro.upload.protocol=arduino
MysensorsMicro.upload.maximum_size=30720
MysensorsMicro.upload.maximum_data_size=2048
MysensorsMicro.upload.speed=57600
MysensorsMicro.bootloader.tool=arduino:avrdude
MysensorsMicro.bootloader.unlock_bits=0x3F
MysensorsMicro.bootloader.lock_bits=0x0F
MysensorsMicro.bootloader.low_fuses=0xE2
MysensorsMicro.bootloader.high_fuses=0xD2
MysensorsMicro.bootloader.extended_fuses=0x06
MysensorsMicro.bootloader.file=DualOptiboot/optiboot_atmega328_pro_8MHz.hex
MysensorsMicro.build.board=AVR_MICRO8
MysensorsMicro.build.core=arduino:arduino
MysensorsMicro.build.variant=micro
MysensorsMicro.build.mcu=atmega328p
#MysensorsMicro.build.f_cpu=8000000L
MysensorsMicro.menu.cpu.8Mhz=Atmega328 8Mhz
MysensorsMicro.menu.cpu.8Mhz.build.f_cpu=8000000L
MysensorsMicro.menu.cpu.1Mhz=Atmega328 1Mhz
MysensorsMicro.menu.cpu.1Mhz.build.f_cpu=1000000LEdit2:
Funktioniert ??? Mit
attr <name> mapReading_voltage3 3 voltagekommt jetzt ein reading voltage3 ...
@All:
Das mit den verlorenen Messages war in diesem Thread (https://forum.fhem.de/index.php/topic,60917.0.html), das klingt irgendwie nicht lustig >:(. Vielleicht hat jemand ja eine Idee, was das eigentliche Problem ist (das mit den Board-Definitionen will mir nicht recht einleuchten, vielleicht vergleiche ich das am WE mal). Ich habe eher den modifizierten NRF-Treiber in Verdacht. Dort wurde - soweit ich das verstanden habe - ein Puffern auf dem NRF eingeführt. Das könnte evtl. ähnliche Folgen haben wie lange Messages (https://forum.mysensors.org/topic/1345/sensebender-micro, ziemlich am Ende des Threads).
EDIT: Hier (https://forum.mysensors.org/topic/5256/gateway-seems-to-keep-resetting) hat jemand dasselbe Problem (kein dauerhafter connect/reboot) mit domiticz...
EDIT2: Hier (https://forum.mysensors.org/topic/4450/sensor-presentation-failure/8) hat jemand (der Entwickler des MyS-NRF-Treibers?) vor einiger Zeit bestätigt, dass es bei zu schnellem Senden zu einem Buffer-Overflow kommen kann und empfohlen, ggf. ein "wait(50)" einzubauen...
@PeMue:
Schön, dass es endlich geklappt hat!
Was die NRF angeht: hätte für Tests noch einen bunten Strauß aus diversen Quellen hier liegen, bei Interesse PM und wir klären den Rest beim nächsten Treffen @Gässles-Stüble ;D.
Legt FHEM bei einer Neuanlage des Devices immer noch automatisch auch ein value-Reading an? (Das dürfte ohne die Präsentation eines entsprechenden Childs eigentlich nicht passieren!!!!)
Dein Beitrag hat mich übrigens auf eine Idee gebracht, wie ich den Update-Bootloader ohne größere Klimmzüge auf meine Boards bringen könnte ;D:
MysensorsMicro.bootloader.file=DualOptiboot/optiboot_atmega328_pro_8MHz.hex Und in der IDE gab es doch irgendwo die Option "Bootloader flashen"...
@PeMue
ZitatBoarddefinition: Sensebender Micro (https://raw.githubusercontent.com/mysensors/ArduinoBoards/master/package_mysensors.org_index.json), wo das installiert wird, habe ich noch nicht herausgefunden
kommt unter "Datei => Voreinstellungen => Zusätzliche Boardverwalter" rein, sollte da schon einer drinn stehen (z.B. vom ESP8266) hinten auf den Kasten klicken und da dann einen Eintrag pro Zeile. Das Board selber installiert man dann über den Boardverwalter wie beim ESP.
Edit: Hier (https://github.com/arduino/Arduino/wiki/Unofficial-list-of-3rd-party-boards-support-urls) sind noch ein paar Interessante dabei
@Beta
"Bootloader brennen" findeste im Menu "Werkzeuge" gaaaanz unten. Vorher das passende Board einstellen und den Comport auf den Comport vom ISP einstellen dann brennen. Zum Schluss noch Comport wieder auf das Board mit dem neuen Bootloader umstellen und das Programm Flashen.
Wegen der Board-Definitionen: Da hab ich bisher noch NIE was ausgetauscht immer mit der Original Installierten gearbeitet und hat immer funktioniert. Wenn was net funktioniert liegt es entweder an der verwendeten Lib oder am Programm.
@Beta-User:
Danke für Dein MySensors Starter Guide, das macht einige Dinge doch etwas transparenter.
Allerdings sind mir ein paar Dinge noch nicht wirklich klar (ich beziehe mich auf den obigen SensbenderMicro Sketch).
In setup() wird die komplette Initialisierung übernommen.
Danach kommt die presentation(), wo der node mit dem gateway Verbindung aufnimmt. Warum ist dann im setup folgender Sendebefehl drin:
sendTempHumidityMeasurements(false);
sendBattLevel(false);
Die können doch erst nach erfolgter presentation abgesetzt werden, oder?
Jetzt ist mir auch klar, warum die Batteriespannung so spät aufgetaucht ist: die wird das erste Mal 60*60 s = nach einer Stunde ausgegeben :(
Daher würde ich in obigem code einfach das false durch true ersetzen und sofort nach Einschalten des Sensors die Werte senden.
Danke + Gruß
Peter
@PeMue:
Danke für die Blumen! Und Bitte um Info, wenn irgendwas auffällt. Ist doch schwer, wenn einem (vermeintlich ;)) die Dinge klar sind, dann denkt man manchmal: steht doch da. Und überliest dann die Dinge in den Basisdokumenten (API, da hätte man auch selber drauf kommen können, tssss 8).
Was setup()->presentation() bzw. before()->presentation()->setup() angeht: das ist bei 2.0.0 und 2.0.1 unterschiedlich, bei 2.0.0 wird die setup() noch vor presentation() ausgeführt, bei der beta danach. Ich vermute mal, dass man das mit dem before() eigentlich noch in die 2.0.0 einbauen wollte und es dann aus irgendwelchen Gründen kurzfristig doch gelassen hat. Deswegen stimmt an der Stelle auch die offizielle Doku NICHT. (Bin mit Hauswart über das Thema gestolpert bei dieser DS18B20-ID-Sache).
U.a. deswegen mag ich die beta mal wieder mehr ;). Dann kann man nämlich bei before() die SPI-Sachen (mehrere Devices auf dem Bus, auf dem auch der NRF arbeitet) initialisieren und nach presentation() dann mittels setup() einmalige Initialisierungsinfos vom Controller abholen (und Infos wie die Dallas-Adressen verschicken), bevor die loop() startet. Es gibt wohl auch die Option, die presentation() nochmal seitens des Controllers anzustoßen, also eine Art reboot ohne bootloader-Modus.
Wenn jetzt noch der pull-request mit dem Failsafe-Start endlich kommt, ist wieder fast alles gut!
Gruß, Beta-User
So, zum Schluß noch ein paar Erkenntnisse:
1. Die 2.0.1-beta (und vermutlich auch die 2.0.0) scheinen empfindlicher gg. fake-NRF's zu sein als die Vorversionen. Wem Pakete verlorengehen, sollte (auch) das mal prüfen, selbst wenn die Bauteile bisher problemlos waren (Reichweite!).
2. Wenn man zu schnell viele Informationen senden will, geht irgendwann was verloren. Ich hatte hier versucht, 8 DS18B20 auszulesen, da kam nach der 5. Temperatur nix mehr beim GW an. Ein wait(80) in der Lese-Sende-Schleife hat dieses Phänomen beseitigt, vermutlich hätte auch "20" gereicht. (Keine Erfahrung mit signing, aber: Messages mit Signatur nutzen die volle mögliche Payload aus, da geht es lt. MySensors-Forum schneller!).
3. Wer (wie ich) bisher verstanden hatte, dass der IRQ-Pin nicht erforderlich ist: könnte sein, dass sich das demnächst ändert ;).
4. Anders als das von Karl-Heinz2000 beharrt mein serielles GW auf "startup complete" als funktionsfähigem Zustand. Komisch :(.
Damit ist OWX (über USB am PI angebunden mit einem zu langen Kabel) bei mir Vergangenheit! ::)
Jetzt muß ich noch einen kaputten DS18B20 tauschen, dann bin ich erst mal wieder auf Stand :) :) :) :).
Bis demnächst,
Beta-User
Hi,
wer betreut momentan eigentlich MYSENSORS und MYSENSORS_DEVICE? Ich dachte ntruchsess, aber der kommt in diesem Thread hier gar nicht mehr vor?
Ich frage deshalb:
https://forum.fhem.de/index.php/topic,61435.msg528573.html#msg528573
Gruß,
Thorsten
Norbert ist der Eigentümer der Module. Probiere ihm einen (git) pull request zu senden.
Ja Norbert ist der Eigentümer. In der Vergangenheit habe ich ein paar Anpassungen vorgenommen und sie PR an Norbert gesendet und er hat sie eingecheckt.
Ich habe derzeit noch einige Änderungen offen, die ich bis heute leider selbst nicht testen konnte.
Hier ist deine Anpassung:
https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/00_MYSENSORS.pm
Hier die weiteren noch nicht veröffentlichten Änderungen:
https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/10_MYSENSORS_DEVICE.pm
https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/lib/Device/MySensors/Constants.pm
Gruss
Danke!
Wie immer bin ich über Feedback froh :) Dann kann ich sie bald mal bei Norbert vorzeigen.
@Hauswart
hab deine Dateien mal reingepackt wenn du mir jetzt noch sagts was geändert wurde (außer der Erweiterung für den SceneController) teste ich gerne.
Zitat von: kleinerDrache am 28 November 2016, 16:11:26
@Hauswart
hab deine Dateien mal reingepackt wenn du mir jetzt noch sagts was geändert wurde (ausser der erweiterungen für den SceneController) teste ich gerne.
Das Gateway kann man nun löschen, die Windows Anpassung ist drinnen und die neuen MySensors v2.0 Sensoren und Variablen sind integriert.
ah ok also bis auf die neue Anpassung für Windows alles beim alten *gg* ok dann funktionieren die bestens. Windows kann ich nicht testen da Linux System
Ich bin gerade dabei, auf mysensors 2.0 umzusteigen.
Das Ethernet-Gateway (W5100) läuft soweit. Allerdings hauen mir zwei Sensoren das FHEM aus den Fugen, so dass es crasht und neu gestartet werden muss.
Das passiert reproduzierbar wenn der Sensor Strom zum Arbeiten kriegt.
Das sind folgende Sketches:
- DHT, alte Version V1.5.4
- Motion+Lux Kombisensor als V2.0 link: https://forum.mysensors.org/topic/4893/multisensor-pir-and-lux (https://forum.mysensors.org/topic/4893/multisensor-pir-and-lux)
Die Node-ID weise ich direkt im Sketch zu.
Die einzige Fehlermeldung, die im Log steht, ist:
Undefined subroutine &MYSENSORS::DEVICE::sendMessage called at ./FHEM/10_MYSENSORS_DEVICE.pm line 560.
Versionen:
fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig
00_MYSENSORS.pm 9341 2015-10-02 14:55:54Z ntruchsess
10_MYSENSORS_DEVICE.pm 9873 2015-11-12 20:54:45Z ntruchsess
Komischerweise schmiert das FHEM beim Anstecken des Sensors nicht immer weg; manchmal überlebt es - dennoch seltsam...
Hat jemand einen Tipp zur Abhilfe?
Zeig doch mal ein Log vom Gateway mit Verbose = 5. Damit man auch mal sieht, was das Gateway empfängt.
@presskopf:
Welche IDE verwendest Du? Wenn es die Arduino-IDE ist, sollte zum Flashen des GW die Board-Definition <= 1.6.11 sein, sonst bootet das GW ständig. Das muß zwar nicht die Ursache sein, aber die Reboots sind sicher auch nicht hilfreich...
Das fhem-log spukt folgendes aus.
Hier beim Anschalten des DHT-Sensors.
2016.12.05 09:59:09 5: MYSENSORS/RAW: /9;255;3;0;6;0
2016.12.05 09:59:09 5: MYSENSORS Read: Rx: fr=009 ci=255 c=003(C_INTERNAL ) st=006(I_CONFIG ) ack=0 '0'
2016.12.05 09:59:09 5: Triggering MYSENSOR_9 (1 changes)
2016.12.05 09:59:09 5: Notify loop for MYSENSOR_9 parentId: 0
2016.12.05 09:59:09 5: ZE.Batterie: not on any display, ignoring notify
Undefined subroutine &MYSENSORS::DEVICE::sendMessage called at ./FHEM/10_MYSENSORS_DEVICE.pm line 560.
Dann ist Feierabend....
Starte ich danach FHEM neu, ist alles okay. Der fragwürdige Sensor 9 sendet die Messdaten.
@Beta-User:
Danke, das werde ich gleich nachher testen und meine sowas auch schon mal im dunkelsten Eck meines Gedächtnisses gespeichert zu haben.
In der Tat habe ich die mysensors v2.0 fröhlich frei in die Arduino-IDE 1.6.13 genudelt. 8)
Habe jetzt mit Arduino 1.6.10 kompiliert und geflasht.
Leider kein Unterschied. :-\ Das wäre schön gewesen.
Das Absturzlog ist identisch.
Beim anderen Kombisensor (BH1750+ HC-SR501) ergibt sich folgendes Log beim Crash:
2016.12.05 11:54:36 5: MYSENSORS/RAW: /27;255;0;0;17;2.0.0
2016.12.05 11:54:36 5: MYSENSORS Read: Rx: fr=027 ci=255 c=000(C_PRESENTATION) st=017(S_ARDUINO_NODE ) ack=0 '2.0.0'
2016.12.05 11:54:36 5: Triggering global (1 changes)
2016.12.05 11:54:36 5: Notify loop for global ATTR MYSENSOR_27 mode node
2016.12.05 11:54:36 5: ZE.Batterie: not on any display, ignoring notify
2016.12.05 11:54:36 5: Triggering global (1 changes)
2016.12.05 11:54:36 5: Notify loop for global ATTR MYSENSOR_27 version 2.0.0
2016.12.05 11:54:36 5: ZE.Batterie: not on any display, ignoring notify
2016.12.05 11:54:36 5: MYSENSORS/RAW: /27;255;3;0;6;0
2016.12.05 11:54:36 5: MYSENSORS Read: Rx: fr=027 ci=255 c=003(C_INTERNAL ) st=006(I_CONFIG ) ack=0 '0'
2016.12.05 11:54:36 5: Triggering MYSENSOR_27 (1 changes)
2016.12.05 11:54:36 5: Notify loop for MYSENSOR_27 parentId: 0
2016.12.05 11:54:36 5: ZE.Batterie: not on any display, ignoring notify
Undefined subroutine &MYSENSORS::DEVICE::sendMessage called at ./FHEM/10_MYSENSORS_DEVICE.pm line 560.
Auch hier funktioniert der Kombisensor nach dem "service fhem restart".
Zitat von: presskopf am 05 Dezember 2016, 11:58:27
Habe jetzt mit Arduino 1.6.10 kompiliert und geflasht.
Nicht die Arduino-Version ist entscheidend, sondern die Board-Definition (=>Board-Manager). Das geht auch mit der aktuellen IDE, und bei der IDE x.10 dürfte die Board-Def. für de Nanos auch schon auf x.13 gestanden haben...
Trotzdem ist das eine seltsame Fehlermeldung :(.
Aaah, again what learned!
Habe die Boardverwalter 1.6.10 auf IDE 1.6.10 installiert.
Leider kein Unterschied... :(
Hmmm...
Soweit ich das verstehe, hat er ein Problem damit, dass vermeintlich die Senderoutine nicht existiert (in Norberts Variante steht die in Zeile 411 der 00_MYSENSORS.pm).
Kannst Du mal nachsehen, ob evtl. die .pm kaputt ist? (Rechte passen? (fhem:dialout)). Wenn das der Fall ist: ggf. mal mit wget https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/00_MYSENSORS.pm?format=raw (aus dem richtigen Verzeichnis heraus, Rechte wieder anpassen) neu installieren (oder gleich als Tester für die erweiterten Versionen von Hauswart bewerben)???
(
Habe die Datei vom github runtergeladen und verglichen.
Bis auf das return undef; ist alles identisch. Das habe ich damals eingebaut, um ein Gateway auch wieder löschen zukönnen.
root@raspi-4:~# diff 00_MYSENSORS.pm /opt/fhem/FHEM/00_MYSENSORS.pm
116a117
> return undef;
root@raspi-4:~#
Mein Bauch sagt, da liegt bei meiner Installation irgendwas im Argen - obwohl ansonsten alles fluppt...
Irgendwie gehen mir jetzt auch die Ideen aus :(.
Die beiden Devices hast Du sicher auch schon mal gelöscht und wieder anlegen lassen, oder?
Und was ist das für eine ZE.batterie, was da im log steht und die loop auslöst? Jedenfalls in dem verlinkten PIR-lux-sketch wird ja kein batterie-reading mit übertragen. Vielleicht könntest Du da die Child_ID_Light auf was anderes als "0" festlegen. (Ich verwende die in der Regel für "interne" Zwecke, das erste echte Child bekommt die "1" oder höher; sollte eigentlich nicht schaden, aber wer weiß...).
Wenn irgendwo ZE.batterie für ein notify usw. genutzt wird, müßte es unten bei "probably associated with..." auftauchen?
ZE.Batterie habe ich hier geklaut; glaube kaum, dass es damit zu tun hat.
http://www.meintechblog.de/2015/08/fhem-rechtzeitige-benachrichtigung-bei-leeren-batterien/ (http://www.meintechblog.de/2015/08/fhem-rechtzeitige-benachrichtigung-bei-leeren-batterien/)
Ich habe mal auf die Schnelle ein Serial Gateway mit FTDI-Nano und NRF24-Sender zusammengebaut.
Wieder mit 1.6.10 kompiliert und geflasht.
Unglaublich, das bringt mein FHEM ebenfalls zum Crash! :o
Das Log ist aber deutlich umfangreicher:
2016.12.05 17:18:25 5: MYSENSORS/RAW: /0;2
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;2/55;3;0;9;TSP:MSG:READ 27-27-255 s=
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:READ 27-27-255 s=/255,c=3,t=7,pt=0
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:READ 27-27-255 s=255,c=3,t=7,pt=0/,l=0,sg=0:
0;255
2016.12.05 17:18:25 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'TSP:MSG:READ 27-27-255 s=255,c=3,t=7,pt=0,l=0,sg=0:'
2016.12.05 17:18:25 5: MYSENSORS gateway gateway_serial: TSP:MSG:READ 27-27-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;255/;3;0;9;TSP:MSG:B
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:B/C
0;255;3;0;9;TS
2016.12.05 17:18:25 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'TSP:MSG:BC'
2016.12.05 17:18:25 5: MYSENSORS gateway gateway_serial: TSP:MSG:BC
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;255;3;0;9;TS/P:MSG:FPAR REQ (
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:FPAR REQ (/sender=27)
0;2
2016.12.05 17:18:25 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'TSP:MSG:FPAR REQ (sender=27)'
2016.12.05 17:18:25 5: MYSENSORS gateway gateway_serial: TSP:MSG:FPAR REQ (sender=27)
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;2/55;3;0;9;TSP:CHKUP
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:CHKUP/L:OK
0;255;3;0;
2016.12.05 17:18:25 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'TSP:CHKUPL:OK'
2016.12.05 17:18:25 5: MYSENSORS gateway gateway_serial: TSP:CHKUPL:OK
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;255;3;0;/9;TSP:MSG:GWL OK
2016.12.05 17:18:25 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'TSP:MSG:GWL OK'
2016.12.05 17:18:25 5: MYSENSORS gateway gateway_serial: TSP:MSG:GWL OK
2016.12.05 17:18:25 5: MYSENSORS/RAW: /0;255;3;0;
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;255;3;0;/9;TSP:MSG:SEND 0-0
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:SEND 0-0/-27-27 s=255,c=3
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:SEND 0-0-27-27 s=255,c=3/,t=8,pt=1,l=1,sg=0
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:SEND 0-0-27-27 s=255,c=3,t=8,pt=1,l=1,sg=0/,ft=0,st=ok:0
2016.12.05 17:18:25 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'TSP:MSG:SEND 0-0-27-27 s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=ok:0'
2016.12.05 17:18:25 5: MYSENSORS gateway gateway_serial: TSP:MSG:SEND 0-0-27-27 s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=ok:0
2016.12.05 17:18:27 5: MYSENSORS/RAW: /0;255;3;0;
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;/9;TSP:MSG:READ 2
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:READ 2/7-27-0 s=255,c=3,t
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:READ 27-27-0 s=255,c=3,t/=24,pt=1,l=1,sg=
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:READ 27-27-0 s=255,c=3,t=24,pt=1,l=1,sg=/0:1
0;255;3;0;9;
2016.12.05 17:18:27 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'TSP:MSG:READ 27-27-0 s=255,c=3,t=24,pt=1,l=1,sg=0:1'
2016.12.05 17:18:27 5: MYSENSORS gateway gateway_serial: TSP:MSG:READ 27-27-0 s=255,c=3,t=24,pt=1,l=1,sg=0:1
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;/TSP:MSG:PINGED (
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:PINGED (/ID=27, hops=1)
2016.12.05 17:18:27 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'TSP:MSG:PINGED (ID=27, hops=1)'
2016.12.05 17:18:27 5: MYSENSORS gateway gateway_serial: TSP:MSG:PINGED (ID=27, hops=1)
2016.12.05 17:18:27 5: MYSENSORS/RAW: /0;255;3;0
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0/;9;TSP:MSG:SEND 0-
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:SEND 0-/0-27-27 s=255,c=
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:SEND 0-0-27-27 s=255,c=/3,t=25,pt=1,l=1,
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:SEND 0-0-27-27 s=255,c=3,t=25,pt=1,l=1,/sg=0,ft=0,st=ok:1
2016.12.05 17:18:27 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'TSP:MSG:SEND 0-0-27-27 s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=ok:1'
2016.12.05 17:18:27 5: MYSENSORS gateway gateway_serial: TSP:MSG:SEND 0-0-27-27 s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=ok:1
2016.12.05 17:18:27 5: MYSENSORS/RAW: /0;2
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;2/55;3;0;9;TSP:MSG
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG/:READ 27-27-0 s=25
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:READ 27-27-0 s=25/5,c=3,t=15,pt=6,
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:READ 27-27-0 s=255,c=3,t=15,pt=6,/l=2,sg=0:0100
2016.12.05 17:18:27 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'TSP:MSG:READ 27-27-0 s=255,c=3,t=15,pt=6,l=2,sg=0:0100'
2016.12.05 17:18:27 5: MYSENSORS gateway gateway_serial: TSP:MSG:READ 27-27-0 s=255,c=3,t=15,pt=6,l=2,sg=0:0100
2016.12.05 17:18:27 5: MYSENSORS/RAW: /0;255;3;0;
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;/9;!TSP:MSG:SEND
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;!TSP:MSG:SEND /0-0-27-27 s=255,
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;!TSP:MSG:SEND 0-0-27-27 s=255,/c=3,t=15,pt=6,l=2,
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;!TSP:MSG:SEND 0-0-27-27 s=255,c=3,t=15,pt=6,l=2,/sg=0,ft=0,st=fai
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;!TSP:MSG:SEND 0-0-27-27 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=fai/l:0100
2016.12.05 17:18:27 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 '!TSP:MSG:SEND 0-0-27-27 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=fail:0100'
2016.12.05 17:18:27 5: MYSENSORS gateway gateway_serial: !TSP:MSG:SEND 0-0-27-27 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=fail:0100
2016.12.05 17:18:27 5: MYSENSORS/RAW: /0
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0/;255;3;0;9;TSP:M
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:M/SG:READ 27-27-0
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:READ 27-27-0 /s=255,c=3,t=6,pt=1
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:READ 27-27-0 s=255,c=3,t=6,pt=1/,l=1,sg=0:0
2
2016.12.05 17:18:27 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 'TSP:MSG:READ 27-27-0 s=255,c=3,t=6,pt=1,l=1,sg=0:0'
2016.12.05 17:18:27 5: MYSENSORS gateway gateway_serial: TSP:MSG:READ 27-27-0 s=255,c=3,t=6,pt=1,l=1,sg=0:0
2016.12.05 17:18:27 5: MYSENSORS/RAW: 2/7;255;3;0;6;0
2016.12.05 17:18:27 5: MYSENSORS Read: Rx: fr=027 ci=255 c=003(C_INTERNAL ) st=006(I_CONFIG ) ack=0 '0'
2016.12.05 17:18:27 5: Triggering MYSENSOR_27 (1 changes)
2016.12.05 17:18:27 5: Notify loop for MYSENSOR_27 parentId: 0
2016.12.05 17:18:27 5: ZE.Batterie: not on any display, ignoring notify
Undefined subroutine &MYSENSORS::DEVICE::sendMessage called at ./FHEM/10_MYSENSORS_DEVICE.pm line 560.
Das mit der CHILD_ID teste ich später noch...
Zitat von: presskopf am 05 Dezember 2016, 17:21:30
ZE.Batterie habe ich hier geklaut; glaube kaum, dass es damit zu tun hat.
..keine Ahnung, aber das ist das letzte, was im log erscheint. Ich würde die mal einfach zur Sicherheit rausnehmen...
Für mich sieht das auch eher so aus, als wäre es ein FHEM-Problem und nicht eines, was speziell mit MySensors zu tun hat, ist aber auch nur ein Bauchgefühl. (Einer meiner 2.0.0-beta-Sensoren sendet auch regelmäßig ein Battery-Reading, an sich stellt das Reading für sich m.E. kein Problem dar und welche Version, ist auch egal, das Protokoll ist over-the air und seriell nicht geändert, es sind nur neue Readings/Mechanismen dazugekommen; diese werden aber bei den einfachen Sketches noch gar nicht genutzt...).
Was Deine Infrastruktur angeht: An sich ist vermutlich nicht schädlich, was Du verwendest, ich würde aber dennoch eher mal die IDE auf den aktuellen Stand bringen, die Board-Definitionen aber auf 1.6.11 lassen (v.a. auch für das serielle GW, das hat dasselbe Reboot-Problem) und die aktuelle MySensors-beta nehmen (2.1.0-beta).
Vielen Dank für Deine Hilfe @Beta-User !
Es sieht wohl so aus, dass ich, nachdem ich alle Arduino-IDEs, Boardverwalterversionen und Mysensor-branches durchgetestet habe, es wieder stabil habe.
Dein Riecher, dass es FHEM-spezifisch ist, war richtig. Während meines Upgrade des Gateways von 1.5.4 auf 2.0 habe ich das Gateway neu angelegt. Da ein erneutes Anstöpsel sowie ein Neustart das 2.0er Gateway nicht erkannt hat. Den Rest der Mysensors-Defines habe ich nicht angerührt.
Das führte dazu, dass das Gateway nach den Nodes in der fhem.cfg auftaucht, welches dieses seltsame Verhalten anscheinend herbeiführt.
Richtig wäre wohl gewesen:
a) Alle Nodes löschen und neu anlegen
oder
b) In die fhem.cfg eingreifen und den Gateway-Eintrag hochschieben - wie nun getan.
Au Mann, damit kann man zwei Tage verbringen.... >:(
Frage: Wie machen das die Kollegen mit config.db?
Schön, dass jetzt alles wieder läuft!
Zitat von: presskopf am 05 Dezember 2016, 19:50:59
Frage: Wie machen das die Kollegen mit config.db?
Zu configDB@sqlite kann ich nur folgende Erfahrungen liefern (ist hier aber etwas off-topic):
- Umgestellt irgendwann im Frühjahr, der "Bestand" entsprach in etwa dem heutigen, seither wurden eher nur marginale Dinge geändert.
- Vor dem Umstieg hatte ich eine ganze Reihe von includes (Erst die grundsätzlichen Dinge (global usw.) , dann I/O's, dann die "externe" HW nach Typen (HM-Heizung, HM-Rest, MySensors, Milight), dann erst die Logikelemente, um die Übersicht zu behalten und ggf. einfacher wieder was zurückspielen zu können (s.u.)).
- Anlaß für die Umstellung war eine Diskussion mit betateilchen und Cooltux, die der Ansicht waren, dass configDB gerade für "schlichte user" viel unproblematischer sei als das mit den includes, die (vor meiner Rückfrage dazu bereits) intensive Diskussion zwischen den Beiden war nach meiner Erinnerung veranlaßt gewesen durch gerade so ein Reihenfolgethema wie bei Dir ;). Ich hatte das als "Versprechen" verstanden, mich mit solchen Dingen nicht mehr beschäftigen zu müssen (was aber unproblematisch war, da ich ja wußte, in welcher Reihenfolge man die Abhängigkeiten auflösen muß).
- Bisher gab es gefühlt keine Probleme, die auf derartige Reihenfolgethemen wie jetzt aktuell bei Dir zurückzuführen gewesen wären
- Positiv vermerkt habe ich, dass scheinbar Devices, die früher gelöscht gewesen wären (insbes. DS18B20 via USB-OWX) automatisch wieder auftauchten, sobald sie angestöpselt waren. Zuvor hatte ich bei diesen mehrfach den Fall gehabt, dass diese durch ein "save" zum falschen Zeitpunkt gelöscht worden waren und ich die entsprechenden Abschnitte der includes wieder herstellen mußte.
- Probleme dahingehend, dass die DB zu groß würde (über das Problem hatten andere berichtet), habe ich nicht, ca. 32 MB (was im Vergleich zu Textfiles natürlich immer noch riesig ist...)
- Da es die Option gibt, sich eine aktuelle *.cfg als Textfile zu exportieren, mache ich das als Backup hin und wieder und sehe configDB ansonsten als unproblematisch an (auch wenn ich nach wie vor keinen Schimmer habe, was da im Detail passiert).
Wenn Du Fragen zur wirklichen Funktionalität von configDB hast, ist vermutlich betateilchen der richtige Ansprechpartner.
@presskopf Die Fehlerkonstellation bei dir ist mir immer noch etwas rätselhaft... aber gut es läuft wieder :D
Ich verwende ConfigDB (MySQL) soweit ich mich erinnere musste ich damals als ich nach dem Gateway löschen gefragt hatte (und der erfolgreich gelöscht war) auch erst alle noch vorhandenen Reste von MySensors entfernen bevor ich den Gateway neu angelegt habe ,weil mir sonst immer FHEM gecrasht war. Also IMMER den Gateway als erstes im System wie ich das sehe. Ich weis dann bloß nicht wie das ist wenn ich mal nen neuen Gateway einbaue und danach den alten entferne(warum auch immer ;) )?
Hallo,
so, jetzt habe ich mal meinen zweiten SensebenderMicro auf die library v2.0 aktualisiert und - siehe da - er hört nicht mehr nach ein paar Tagen auf. Die leeren Batterien kann ich auch nicht erklären.
Sei's drum, wenn es funktioniert, soll es gut sein. Jetzt muss ich nur noch den Sketch so umbauen, dass er ganz am Anfang die Versorgungsspannung mitschickt und mal einen Referenzsensor daneben stellen, um zu sehen, wie genau die Dinger messen.
Gruß PeMue
Zitat von: PeMue am 06 Dezember 2016, 21:41:31
Jetzt muss ich nur noch den Sketch so umbauen, dass er ganz am Anfang die Versorgungsspannung mitschickt
Moin,
mit der aktuellen 2.1.0-beta geht das recht simpel: Einfach den Sendebefehl zu dem entsprechenden Meßwert in der setup()-Routine unterbringen.
Soweit ich das auf Github gelesen habe, soll die 2.1.0 eine Weihnachtsedition werden, die Codebasis dürfte daher eher einen ziemlich stabilen Zustand erreicht haben... Das hat btw. auch den Vorteil, dass man seitens des Controllers theoretisch das setup() auch erneut ausführen lassen kann, also solche Infos dann bei Bedarf aktiv erfragen könnte.
Gruß, Beta-User
Hallo,
ich versuche mich aktuell auch mit mysensors sensoren. Dazu habe ich mir 8 MQ-X Sensoren für unterschiedliche Gasarten besorgt.
Wie schaffe ich es, mehrere SENSOREN verwenden zu können. Ich möchte ja nicht z.b. nano und MQ-SENSOR JEWEILS 1:1 aufbauen zu müssen. Wären ja bis zu 8 nano.
Wie bekomme ich also z.b. Luftqualität und co2 oder sagen wir mal 4 Sensoren zu laufen?
Da muss ich doch sicherlich mit ext. Netzteilen für power der Sensoren arbeiten. Über den power pin des nano oder mega dürfte ja wegen der Ampere den nano zerstören.
Welches Netzteil?
Grüße
Jörg
...da sich sonst keiner zu trauen scheint...
...zu Stromhunger kann ich nichts sagen ::), vermutlich solltest Du ein Netzteil nehmen, das so angeschlossen werden kann, dass die MQ-x-e direkt (ohne 5V/Ground-Anschluß am Arduino) bedient werden können; unmöglich sollte das vom Gesamtverbrauch her nicht sein, schließlich steht da im Sketch irgendwo was von Batteriebetrieb; evtl. könnte man die einzelnen Sensoren über einen Transistor ein- und ausschalten...
Was das Anschließen angeht, wird pro MQ-x je ein analoger Meßwert erfaßt, dann umgerechnet und übertragen, wenn ich das richtig verstanden habe. Damit sollten (wenn der Speicher reicht) pro Arduino auch 6 MQ-x-e angeschlossen werden können. Es müßte m.E.
- der jeweilige Analog-Pin angepasst werden
- Die Umrechung ist für alle gleich? Diese dann evtl. in eine extra Routine auslagern, sonst halt jeweils angepaßt...
- die Werte sollten vermutlich intern am besten über einen Index und entsprechende Arrays erfaßt bzw. gespeichert und übermittelt werden (ähnlich dem DS18B20-Sketch für mehrere Sensoren). Dazu würde ich nicht mit "0" anfangen, sondern mit "1" (weil FHEM die "0" dann wieder bei der Benennung der Readings unterschlägt).
Wenn das zu kurz oder kryptisch war, bitte melden.
Gruß und guten Rutsch,
Beta-User
ohm sorry garnet gesehen *gg*
Für die Gassensoren UNBEDINGT entweder direkt an die Batterie gehen oder per Netzteil und IMMER mit nem Transistor schalten die Dinger verbraten einiges an mA an Strom (einige über 100) und davon kann der
Arduino an den Pins nur INSGESAMMT in Summe für alles maximal glaube ca 40 mA liefern. Aber denke eher mit Netzteil da die Sensoren der MQ Reihe alle mit einer Heizung für die Gase arbeiten und diese eine bestimmte Zeit braucht bis da halbwegs stabile Werte rauskommen. Ansonsten kann ich Beta nur zustimmen.
Hallo,
Die Version 2.1.0 ist jetzt Release und was ich auch entdeckt es werden jetzt nicht nur die NRF24L01+ unterstützt sondern auch die RFM69HW (868MHz), wo schon Reichweiten bis 5,8km bei freier Sicht erzielt wurden.
Mich würde hier mal interessieren was ihr so im Outdoor Bereich an Reichweiten erzielt habt besonders ohne Sichtverbindung und mit welchem System?
Ich habe mir jetzt auch mal ein paar RFM69HW für das Gateway und RFM69W Module für die Sensoren bestellt.
Ich bin auf die Reichweite gespannt und werde berichten.
hallo zusammen,
bis gestern hatte ich mySensors 2.0.0 im Einsatz, testweise mit einem Relay Aktuator, mit Standard Sketches aus mysensors.org ohne Änderungen (nur IP und NODE-ID)
Es hat auch alles tadellos funktioniert.
Meine Config:
define MySensorGateway MYSENSORS 192.168.178.166:5003
attr MySensorGateway autocreate 1
attr MySensorGateway first-sensorid 1
attr MySensorGateway fp_COCKPIT 63,1349,1,mysensors gateway,
attr MySensorGateway requestAck 1
attr MySensorGateway room mySensors
attr MySensorGateway stateFormat connection
define MYSENSOR_3 MYSENSORS_DEVICE 3
attr MYSENSOR_3 IODev MySensorGateway
attr MYSENSOR_3 mapReading_power1 1 power
attr MYSENSOR_3 mapReading_status1 1 status
attr MYSENSOR_3 requestAck 1
attr MYSENSOR_3 room mySensors
attr MYSENSOR_3 setCommands on:status1:on off:status1:off
attr MYSENSOR_3 setReading_power1 1
attr MYSENSOR_3 setReading_status1 on,off
attr MYSENSOR_3 stateFormat status1
Jetzt nach dem Update auf 2.1.0:
- Im seriellen Monitor ist das Gateway fehlerfrei, Sensor kann man hardwaremässig triggern und meldet erfolg und bekommt Acknowledge vom Gateway
- autocreate funktioniert nicht mehr
- manuelles Schalten des Sensors im FHEM (s.Bild) führt nur dazu, dass das Gateway verschwindet/auftaucht, Sensor bewegt sich nicht:
Zitat
2017.01.04 14:43:22 1: 192.168.178.166:5003 disconnected, waiting to reappear (MySensorGateway)
2017.01.04 14:43:22 1: 192.168.178.166:5003 reappeared (MySensorGateway)
2017.01.04 14:43:23 1: 192.168.178.166:5003 disconnected, waiting to reappear (MySensorGateway)
2017.01.04 14:43:23 1: 192.168.178.166:5003 reappeared (MySensorGateway)
2017.01.04 14:43:26 1: 192.168.178.166:5003 disconnected, waiting to reappear (MySensorGateway)
2017.01.04 14:43:26 1: 192.168.178.166:5003 reappeared (MySensorGateway)
2017.01.04 14:43:28 1: 192.168.178.166:5003 disconnected, waiting to reappear (MySensorGateway)
2017.01.04 14:43:28 1: 192.168.178.166:5003 reappeared (MySensorGateway)
eine Idee ?
Danke&Gruss
Tony
Hallo tonyf
ich würde so vorgehen:
Gateway wieder auf 2.0.0 zurückflashen, wenn sonst nix geändert wurde müsste Dein Actor wieder funktionieren
Geht trotzdem nicht? Dann mal fhem beenden (oder das MySensors Gateway Devive de-aktivieren) und mit dem MSysController testen, läuft mit Netzwerk-Gateway, wie bei Dir, auch unter Linux (mit wine).
Wenn das auch nicht geht, hat sich vielleicht die IP des Gateways geändert? Der MySensors Netzwerk Gateway Sketch offeriert eine einfache Telnet-ähnliche Netzwerkschnittstelle unter IP und Port 5003. Die kann man auch mit telnet oder puTTY öffnen:
telnet 192.168.0.118 5003
0;0;3;0;2;
0;255;3;0;2;2.0.1-beta
Die Eingabe 0;0;3;0;2; ist der Code zur Abfrage der Versionsnummer. Auf meinem Netzwerkgateway läuft derzeit 2.0.1-beta, wie man aus der Antwort des Gateways erkennen kann: 0;255;3;0;2;2.0.1-beta
Wenn Du noch nicht mal mit Telnet oder puTTY was mit dem Gateway anfangen kannst, dann funktioniert entweder der Sketch oder Dein Netzwerk nicht wie gewünscht.
Wenn der FHEM MySensors Gateway Code gestartet wird, baut er eine Netzwerkverbindung zum Port 5003 auf und sendet die Versionsabfrage an das MySensors Gateway. Danach lauscht der FHEM Code nur auf MySensors Sensoren Nachrichten oder gibt Actor Nachrichten an das MySensors Netzwerk weiter. Kann man ähnlich (aber schöner) im MSysController sehen und testen.
Bin gespannt, was bei Dir als Fehlerursache rauskommt.
~josef
@hauswart oder ?
Folgendes Problem:
Man hat ein MySensors Netzwerk-Gateway und ausschließlich Batterie-optimierte Sensoren. Die Sensoren senden nur ganz selten Updates zum Gateway.
FHEM wird mit MySensors Definitionen gestartet, der Gateway antwortet brav auf die Versionsbfrage und dann passiert eigentlich nichts mehr ausser, ein Sensor sendet eine Nachricht an das Gateway. Man weiss nicht, ob der Gateway noch mit FHEM verbunden ist, es sei denn man vermisst die Sensor-Updates.
Mein (erster) Sensor sendet beim Einschalten und dann alle 5 Minuten ein Update. In meinem Fall war des öfteren der Gateway nicht mehr mit FHEM verbunden. Dies stellte ich fest, nachdem ich MSysController auf das selbe Gateway verbunden hatte und dort die Sensor-Updates angezeigt wurden, aber in FHEM nicht.
Ich habe habe dann in FHEM ein set Disconnect und dann set Connect machen müssen, damit die Sensorupdates auch in FHEM ankommen.
Das Problem ist, dass normalerweise keine Kommunikation zwischen FHEM und Gateway stattfindet. Der FHEM keep_alive Timeout für das erste keep_alive Paket wird systembedingt erst nach 2 Stunden! gesendet, dann alle 75 Sekunden (könnte man in DevIO.pm mit Socketoptionen für FHEM anpassen). Also würde mann eventuell erst nach fast zwei Stunden feststellen, das der Gateway nicht mehr mit FHEM verbunden ist.
Das ist leider bei MySensors im Bezug auf das Netzwerk-Gateway nicht beachtet worden.
Abhilfe könnte man zB durch eine periodische Abfrage der Gateway Versionsnummer aus FHEM heraus schaffen. Dazu müsste aber der 00_MySensors code angepasst werden. Wiederholung meiner vorgeschlagenen Änderung:
--- 00_MYSENSORS.pm.org 2017-01-04 19:26:36.437086228 +0100
+++ 00_MYSENSORS.pm 2017-01-04 07:44:12.811919078 +0100
@@ -19,7 +19,7 @@
# You should have received a copy of the GNU General Public License
# along with fhem. If not, see <http://www.gnu.org/licenses/>.
#
-# $Id$
+# $Id: 00_MYSENSORS.pm 9341 2015-10-02 14:55:54Z ntruchsess $
#
##############################################
@@ -218,6 +218,19 @@
return undef;
}
+# GetConnectStatus
+sub GetConnectStatus($){
+ my ($hash) = @_;
+ my $name = $hash->{NAME};
+ Log3 $name, 4, "MySensors: GetConnectStatus called ...";
+
+ #query version from gateway
+ sendMessage($hash, radioId => 0, childId => 0, cmd => C_INTERNAL, ack => 0, subType => I_VERSION, payload => '');
+
+ # neuen Timer starten in einem konfigurierten Interval.
+ InternalTimer(gettimeofday()+300, "MYSENSORS::GetConnectStatus", $hash);
+}
+
sub Timer($) {
my $hash = shift;
my $now = time;
@@ -247,6 +260,8 @@
Log3 ($name, 5, "MYSENSORS/RAW: $data/$buf");
$data .= $buf;
+ readingsSingleUpdate($hash,"lastRead","$buf",1);
+
while ($data =~ m/\n/) {
my $txt;
($txt,$data) = split("\n", $data, 2);
@@ -348,6 +363,8 @@
my $client = shift;
MYSENSORS::DEVICE::onGatewayStarted($client);
});
+ #start connect watch thread, interval 500
+ InternalTimer(gettimeofday()+300, "MYSENSORS::GetConnectStatus", $hash);
last;
};
$type == I_VERSION and do {
Damit wird zum einen jede empfangene Nachricht als lastRead (mit Zeitstempel) in FHEM angezeigt und mann eine Watchdog draufsetzen. Und zum anderen sendet der Code alle 5 Minuten eine Versionsabfrage an das Gateway.
Das Gateway gibt ja noch nicht mal ein OK zurück, wenn man was schickt. Entweder kommt einen Antwort oder eben nix.
Man könnte auch den Gateway Sketch ändern, und alle paar Minuten etwas zum Host schicken. Dann müsste aber auch 00_MySensors angepasst werden.
Bei einem seriell angebunden Gateway kommt die Netzwerk-Problemmatik nicht zum tragen. Wenn man den Gateway 'abzieht' bekommt FHEM das sofort mit, Ist halt ne Hardware-Verbindung. Ob der Gateway aber noch 'lebt', weill vielleicht der Sketch spinnt, weiss man bei dem seriellen Gateway auch nicht ohne periodische Abfrage.
Bei mir läuft sowohl die DevIO socket Änderung als auch o.g. periodische Abfrage. So weiss ich mit ziemlicher Sicherheit, ob mein Gateway noch lebt.
~Josef
Ich finde die Änderungen sehr gut, die du gemacht hast und hoffe, dass sie übernommen werden.
Ansonsten könnte man wie von dir vorgeschlagen auch den Gateway Sketch abändern und einen "lokalen Sensor" am Gateway simulieren. Ich dachte hier an einen einfachen Counter welcher alle 5 Minuten inkrementiert wird. Der Counter wird in FHEM wie ein normaler Node angelegt und hierüber könnte man auch einen Watchdog triggern.
Ich war leider arbeitsbedingt die letzten Wochen wieder stark eingespannt und habe auch zwischen Weihnachten und Neujahr leider keine Zeit gefunden. Heute Nachmittag sollte ich jedoch ein paar Minuten finden und mal die längst gemachten Änderungen an Norbert senden, damit diese in offizielle Release kommen.
Deine Änderung schaue ich mir auch gleich mal an.
Edit: Ich habe hjgode's Patch mal hier eingebaut: https://raw.githubusercontent.com/Kolbi/fhem-mirror/Kolbi-patch-2/fhem/FHEM/00_MYSENSORS.pm (https://raw.githubusercontent.com/Kolbi/fhem-mirror/Kolbi-patch-2/fhem/FHEM/00_MYSENSORS.pm) bitte testen :)
Der Gateway Lösch Patch und der Windows Fix sind bereits als Pull Request bei Norbert. Die Library Anpassungen noch nicht, die möchte ich selbst eigentlich vorher mal testen.
*kaffee*
Zitat von: Hauswart am 05 Januar 2017, 08:36:36
die längst gemachten Änderungen an Norbert senden, damit diese in offizielle Release kommen.
@Hauswart,
zur Info: habe den Stand von ca. Ende Nov. seit Installation ohne erkennbare Probleme im Einsatz (serielles GW mit 2.1 bzw. 2.1-beta), seither allerdings auch kein neuen Sensoren mehr aufgebaut.
@tonyf:
Ist das ein WIFI-GW oder ein Ethernet-GW?
Jedenfalls bei den Arduino-Varianten unter Verwendung der Arduino-IDE ist evtl. ein Downgrade der Board-Definitionen (<=1.6.11) ein Weg, um dauernde Reboots zu verhindern (das scheint auch bei der IDE 1.8 noch nicht behoben zu sein, habe es aber nicht ausgiebig getestet); bei den Reboots gehen auch Daten verloren.
Es gibt auch für die Sensbender-ESP's eigene Board-Definitionen; ob die dasselbe Thema addressieren, weiß ich allerdings nicht. Hast Du diese ggf. verwendet?
Zitat von: Beta-User am 05 Januar 2017, 09:15:08
@Hauswart,
zur Info: habe den Stand von ca. Ende Nov. seit Installation ohne erkennbare Probleme im Einsatz (serielles GW mit 2.1 bzw. 2.1-beta), seither allerdings auch kein neuen Sensoren mehr aufgebaut.
Dann werde ich diesen Teil heute auch via Pull Request an Norbert senden. :)
Guten morgen zusammen,
danke für die antworten.
Es handelt sich un Ethernet Gateway mit Arduino Nano und mySensors V 2.1.0 volle Version, welche vor kurzen freigegeben wurde, also kein Beta.
Das Problem mit den Board-Definitionen und IDE ist mir bekannt. 2.0.0 habe ich mit IDE 1.6.9 eingesielt und hat sehr gut funktioniert.
Jetzt verwende ich IDE 1.8.0, 2.0.0 macht natürlich Probleme - das ist bekannt -, komischerweise ist das nicht der Fall bei 2.1.0. Es lässt sich wunderbar einspielen ohne das ständige Gateway Reboot.
@hjgode: telnet 192.168.168.166 5003 funktioniert, die Abfrage liefert aber kein Ergebnis
Gateway und Aktor funktioneren ausserhalb FHEM problemlos.
das Gateway, sauberer Start ohne Reboots:
Zitat
0;255;3;0;9;MCO:BGN:INIT GW,CP=RNNGA--,VER=2.1.0
0;255;3;0;9;TSM:INIT
0;255;3;0;9;TSF:WUR:MS=0
0;255;3;0;9;TSM:INIT:TSP OK
0;255;3;0;9;TSM:INIT:GW MODE
0;255;3;0;9;TSM:READY:ID=0,PAR=0,DIS=0
0;255;3;0;9;MCO:REG:NOT NEEDED
IP: 192.168.178.166
0;255;3;0;9;MCO:BGN:STP
0;255;3;0;9;MCO:BGN:INIT OK,TSP=1
Der Relay-Aktor mit Button:
Zitat
0 MCO:BGN:INIT REPEATER,CP=RNNRA--,VER=2.1.0
3 TSM:INIT
4 TSF:WUR:MS=0
11 TSM:INIT:TSP OK
13 TSF:SID:OK,ID=3
15 TSM:FPAR
51 TSF:MSG:SEND,3-3-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2058 !TSM:FPAR:NO REPLY
2060 TSM:FPAR
2096 TSF:MSG:SEND,3-3-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2375 TSF:MSG:READ,0-0-3,s=255,c=3,t=8,pt=1,l=1,sg=0:0
2380 TSF:MSG:FPAR OK,ID=0,D=1
4104 TSM:FPAR:OK
4105 TSM:ID
4106 TSM:ID:OK
4108 TSM:UPL
4111 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
4120 TSF:MSG:READ,0-0-3,s=255,c=3,t=25,pt=1,l=1,sg=0:1
4125 TSF:MSG:PONG RECV,HP=1
4128 TSM:UPL:OK
4129 TSM:READY:ID=3,PAR=0,DIS=1
4134 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
4141 TSF:MSG:READ,0-0-3,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
4148 TSF:MSG:SEND,3-3-0-0,s=255,c=0,t=18,pt=0,l=5,sg=0,ft=0,st=OK:2.1.0
4156 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0
6164 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=11,pt=0,l=14,sg=0,ft=0,st=OK:Relay & Button
6173 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:1.0
6192 TSF:MSG:SEND,3-3-0-0,s=3,c=0,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
6198 MCO:REG:REQ
6201 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
8208 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
8214 TSF:MSG:READ,0-0-3,s=255,c=3,t=27,pt=1,l=1,sg=0:1
8219 MCO:PIM:NODE REG=1
8222 MCO:BGN:STP
8223 MCO:BGN:INIT OK,TSP=1
16793 TSF:MSG:SEND,3-3-0-0,s=3,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=OK:1
16802 TSF:MSG:READ,0-0-3,s=3,c=1,t=2,pt=1,l=1,sg=0:1
16806 TSF:MSG:ACK
This is an ack from gateway
Incoming change for sensor:3, New status: 1
22012 TSF:MSG:SEND,3-3-0-0,s=3,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=OK:0
22022 TSF:MSG:READ,0-0-3,s=3,c=1,t=2,pt=1,l=1,sg=0:0
22026 TSF:MSG:ACK
This is an ack from gateway
Incoming change for sensor:3, New status: 0
26494 TSF:MSG:SEND,3-3-0-0,s=3,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=OK:1
26504 TSF:MSG:READ,0-0-3,s=3,c=1,t=2,pt=1,l=1,sg=0:1
26508 TSF:MSG:ACK
This is an ack from gateway
Incoming change for sensor:3, New status: 1
30884 TSF:MSG:SEND,3-3-0-0,s=3,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=OK:0
30894 TSF:MSG:READ,0-0-3,s=3,c=1,t=2,pt=1,l=1,sg=0:0
30898 TSF:MSG:ACK
This is an ack from gateway
Incoming change for sensor:3, New status: 0
Man sieht, ich kann umschalten ohne Probleme und Relay klackert anständig.
Mit FHEM will es einfach nicht, keine Reaktion ausser Schwankung des Gateways.
Gruss
Tony
ZitatMit FHEM will es einfach nicht, keine Reaktion ausser Schwankung des Gateways.
Dann würde ich ein Backup der fhem.cfg machen, FHEM beenden, dann alles zu MySensors aus der fhem.cfg entfernen und dann FHEM neu starten. Anschliessend den Gateway neu anlegen und sehen, ob er sich dann normal benimmt. Falls das auch nicht geht, die FHEM Module (pm Dateien) zu MySensors prüfen. Nicht dass in den Dateien was kaputt ist.
~josef
Zitat von: hjgode am 05 Januar 2017, 11:01:42
Dann würde ich ein Backup der fhem.cfg machen, FHEM beenden, dann alles zu MySensors aus der fhem.cfg entfernen und dann FHEM neu starten. Anschliessend den Gateway neu anlegen und sehen, ob er sich dann normal benimmt. Falls das auch nicht geht, die FHEM Module (pm Dateien) zu MySensors prüfen. Nicht dass in den Dateien was kaputt ist.
~josef
Verwendest du die ganz normalen Stable Dateien? Oder meine Dev?
Hast du mir den Sketch (oder Link) zum Sensor?
Danke ..
das hat nichts gebracht,
FHEM ist aktuell, mySensors Modul ist der stable.
Gateway: https://www.mysensors.org/build/ethernet_gateway -> Änderung nur die IP nach 192.168.178.166
Relay mit Button: https://www.mysensors.org/build/relay -> Änderung nur eingefügt MY_NODE_ID 3
Gruss
Tony
Hallo zusammen,
Zitat von: Beta-User am 05 Januar 2017, 09:15:08
Jedenfalls bei den Arduino-Varianten unter Verwendung der Arduino-IDE ist evtl. ein Downgrade der Board-Definitionen (<=1.6.11) ein Weg, um dauernde Reboots zu verhindern (das scheint auch bei der IDE 1.8 noch nicht behoben zu sein, habe es aber nicht ausgiebig getestet); bei den Reboots gehen auch Daten verloren.
irgendwie kompiliert die Arduino IDE nicht mehr mit der Board Definition 1.6.16. Da kommt folgender Fehler beim Blink Sketch:
cc1.exe: error: -fno-fat-lto-objects are supported only with linker plugin.
Error compiling.(Windows XP bzw. Windows 7, Board Definition s.o.).
Wo seht ihr, dass die Board Definition einen Fehler hat? Welche Board Definition sollte man verwenden?
Der ganze Spaß hat mich jetzt knapp 3 Tage gekostet >:( >:( >:(
Danke + Gruß
PeMue
Zitat von: tonyf am 05 Januar 2017, 12:06:09
Danke ..
das hat nichts gebracht,
FHEM ist aktuell, mySensors Modul ist der stable.
Gateway: https://www.mysensors.org/build/ethernet_gateway -> Änderung nur die IP nach 192.168.178.166
Relay mit Button: https://www.mysensors.org/build/relay -> Änderung nur eingefügt MY_NODE_ID 3
Gruss
Tony
Möglicherweise liegt es an der IP? Ich habe zuerst auch eine statische IP versucht (MySensors 2.0.1-beta), ging irgendwie nicht. Deshalb läuft der Sensor bei mir mit DHCP und einer reservierten IP.
Zitat von: tonyf am 05 Januar 2017, 12:06:09
Danke ..
das hat nichts gebracht,
FHEM ist aktuell, mySensors Modul ist der stable.
Gateway: https://www.mysensors.org/build/ethernet_gateway (https://www.mysensors.org/build/ethernet_gateway) -> Änderung nur die IP nach 192.168.178.166
Relay mit Button: https://www.mysensors.org/build/relay (https://www.mysensors.org/build/relay) -> Änderung nur eingefügt MY_NODE_ID 3
Gruss
Tony
Fehler gefunden S_BINARY wird vom aktuellen Stable noch nicht unterstützt. Sprich meine Dev-Versionen sollten aber eigentlich gehen.
Lösung: Entweder auf den Patch im FHEM Stable warten, davor muss ich den Pull Request Norbert senden er ihn implementieren usw. oder meine Dev-Dateien (ein paar Seiten vorher) vorab testen.
Hier die Links:
Zitat
Hier die weiteren noch nicht veröffentlichten Änderungen:
https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/10_MYSENSORS_DEVICE.pm (https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/10_MYSENSORS_DEVICE.pm)
https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/lib/Device/MySensors/Constants.pm (https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/lib/Device/MySensors/Constants.pm)
Zitat von: PeMue am 05 Januar 2017, 12:35:30
Wo seht ihr, dass die Board Definition einen Fehler hat? Welche Board Definition sollte man verwenden?
"Sehen" ist zu viel gesagt. Auf meinem Laptop (Kubuntu 16.04) ist auch die IDE 1.8 installiert (bringt Board-Def. für Nanos 1.6.16 mit?). Damit habe ich den seriellen GW-Sketch (wie alles folgende MyS. 2.1) auf einen CH340-Nano geflasht, diesen kurz an meinem Test-PI ( :)) in Betrieb genommen und einen weiteren Nano zum Repeater gemacht. Da das soweit (mit den "alten" .pm-Modulen) lief (auch autocreate, das ich aber erst einschalten mußte), habe ich dann mein Haupt-GW (FTDI) auch auf 2.1 gebracht. Dabei habe ich dann nach einem kurzen Test den Eindruck gehabt, dass nicht alle Werte von der wichtigsten Node geliefert werden und dann das Flashen dieses GW's mit der Board-Def. 1.6.11 wiederholt (auf meinem Haupt-PI laufen Hauswarts Modul-Versionen von ca. Ende Nov. 16).
Seither (Sa. oder So.) läuft das FTDI-Nano-GW problemlos, Compiler-Probleme hatte ich zu keinem Zeitpunkt. Die Sketches liegen wie die MySensors-libs in Verzeichnis "~/Arduino", die IDE in "~/Arduino 1.8" (parallel ist noch die letzte 1.6..er Version installiert). Beim ersten Starten der 1.8-er IDE kam der Hinweis, dass es Aktualisierungen von libs gäbe, in dem Zug habe ich das über die IDE auf 2.1 ungedated, auch das update liegt ziemlich sicher unter "~/Arduino" im seitherigen Unterverzeichnis.
(Was ich bislang noch nicht gemacht habe, ist die Ergänzungen für den OTA-Bootloader in die Board-Def. einzupflegen (daher lassen sich jetzt manche pro minis noch nicht flashen, die den Boot-Loader drauf haben, das war das einzige Problem beim flashen)).
Hilft Dir das was?
Zitat von: Hauswart am 05 Januar 2017, 13:15:51
Fehler gefunden S_BINARY wird vom aktuellen Stable noch nicht unterstützt. Sprich meine Dev-Versionen sollten aber eigentlich gehen.
Lösung: Entweder auf den Patch im FHEM Stable warten, davor muss ich den Pull Request Norbert senden er ihn implementieren usw. oder meine Dev-Dateien (ein paar Seiten vorher) vorab testen.
Es sollte auch gehen, das Reading manuell anzulegen.
Zitat von: Beta-User am 05 Januar 2017, 13:21:48
Es sollte auch gehen, das Reading manuell anzulegen.
Stimmt. Müsste es dann nicht so sein? Habe schon lange keine Sensoren von Hand angelegt?
Zitatdefine MYSENSOR_3 MYSENSORS_DEVICE 3
attr MYSENSOR_3 IODev MySensorGateway
attr MYSENSOR_3 mapReading_status1 1 status
attr MYSENSOR_3 requestAck 1
attr MYSENSOR_3 room mySensors
attr MYSENSOR_3 setCommands on:status1:1 off:status1:0
attr MYSENSOR_3 setReading_status1 1,0
attr MYSENSOR_3 stateFormat status1
Der Sketch erwartet ein Bool (1 oder 0)?
Status On sendet eine 1; Staus Off sendet eine 0?
Danke ..
habe die DEV Version eingespielt -> Fehler besteht noch
Status mit 1,0 angepasst -> Fehler noch da
Ich glaube auch nicht, dass es an der IP liegt, es sind 1:1 die gleichen Einstellungen wie bei der 2.0.0 version.
Gruss
Tony
Nebelstocher...
Die Definition des GW steht in der fhem.cfg vor der Sensor-Node?
Anbindung zufällig via PowerLAN?
Zitat von: Beta-User am 05 Januar 2017, 14:20:35
Nebelstocher...
Die Definition des GW steht in der fhem.cfg vor der Sensor-Node?
Anbindung zufällig via PowerLAN?
GW zuerst dann die Nodes - wie in meinem ersten Email/Beitrag.
Es ist eine direkte LAN Anbindung, kein PowerLAN.
Gruss
Tony
Verwendest Du GatewayW5100.ino
vielleicht Schreibfehler in der Zeile:
#define MY_IP_ADDRESS 192,168,178,66
oder aber, verwende mal eine andere MAC Adresse
#define MY_MAC_ADDRESS 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED
Die Netzwerk-Kommunikation läuft über MAC Adressen. Wenn da Mist oder eine im Netz schon bestehende Adresse benutzt wird, dann wird es lustig. Über mögliche Fehlersuche mit arp, wireshark etc. lasse ich mich jetzt nicht aus.
Das mit der MAC habe ich nicht, da ich einen ESP8266 Gateway habe. Die ESPs haben eine Hardware MAC-Adresse.
Aber, MSyscontroller geht mit dem Ding? Hmmm, ist dann wohl doch eine FHEM Geschichte. "Global verbose 5" logs?
::)
Ich habe mit der aktuellen Version(2.1 MySensors) scheinbar empfangprobleme. Bei mir sind 3 Sensebender micro im Einsatz und ich Empfange gerade mal einen davon, der direkt auf der anderen Seite der Wand vom Gateway ist.
Als Gateway verwende ich einen Arduino Nano mit NRF Modul (ohne extra Antenne). Die Micros haben auch alle das normale NRF Modul. Vor dem update habe ich die anderen beiden Sensoren auch empfangen. Hat noch jemand ähnliche Probleme oder gibt es hier ggf schon einen Fix?
Grüße
Gizmoh
Danke hjgode ..
ja ich habe W5100.
aber am Netz und Einstellungen liegt es garantiert nicht, sonst würde kein Ping/Telnet funktionieren, ausserdem sieht man in FHEM (s.Bild im ersten Beitrag), dass das Gateway "connected" ist.
Ich vermute, 2.1.0 und FHEM reden irgenwo aneinander vorbei.
Gruss
Tony
Hallo Tony
das Connected bedeutet leider gar nix, nur das der erste Verbindungsaufbau geklappt hat.
Wie sieht's denn mit FHEM verbose 5 logs aus?
~josef
hi Josef,
das Log mit verbose 5:
Zitat
2017.01.05 15:52:00 3: telnetPort: port 7072 opened
2017.01.05 15:52:00 3: WEB: port 8083 opened
2017.01.05 15:52:00 3: WEBphone: port 8084 opened
2017.01.05 15:52:00 3: WEBtablet: port 8085 opened
2017.01.05 15:52:00 3: Opening CUL433 device /dev/ttyACM0
2017.01.05 15:52:00 3: Can't open /dev/ttyACM0: Datei oder Verzeichnis nicht gefunden
2017.01.05 15:52:00 1: Including /opt/fhem/FHEM/headers.cfg
2017.01.05 15:52:00 1: Including /opt/fhem/FHEM/belueftung.cfg
2017.01.05 15:52:00 3: FHEM2FHEM opening Ventilation at ventilation.fritz.box:7072
2017.01.05 15:52:00 1: Including /opt/fhem/FHEM/garten.cfg
2017.01.05 15:52:01 1: Including /opt/fhem/FHEM/alarmsystem.cfg
2017.01.05 15:52:01 1: Including /opt/fhem/FHEM/rollos.cfg
2017.01.05 15:52:01 1: Including /opt/fhem/FHEM/wetter.cfg
2017.01.05 15:52:01 1: Including /opt/fhem/FHEM/audio.cfg
2017.01.05 15:52:01 1: Including /opt/fhem/FHEM/online.cfg
2017.01.05 15:52:01 1: Including /opt/fhem/FHEM/weblinks.cfg
2017.01.05 15:52:01 1: Including /opt/fhem/FHEM/fritz.cfg
2017.01.05 15:52:01 3: Opening myFritz device fritz.box:1012
2017.01.05 15:52:01 3: FB_CALLMONITOR (myFritz) - loading cache file /opt/fhem/log/reverse-search.txt
2017.01.05 15:52:01 2: FB_CALLMONITOR (myFritz) - read 16 contacts from Cache
2017.01.05 15:52:02 1: Including /opt/fhem/FHEM/widgets.cfg
2017.01.05 15:52:02 1: Including /opt/fhem/FHEM/temperaturen.cfg
2017.01.05 15:52:03 1: Including /opt/fhem/FHEM/outdoor.cfg
2017.01.05 15:52:03 3: FHEM2FHEM opening OUTDOOR11 at outdoor-11.fritz.box:7072
2017.01.05 15:52:03 3: FHEM2FHEM opening OUTDOOR7 at outdoor-7.fritz.box:7072
2017.01.05 15:52:03 1: Including ./log/fhem.save
2017.01.05 15:52:03 3: Opening MySensorGateway device 192.168.178.166:5003
2017.01.05 15:52:03 5: MYSENSORS send: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=002(I_VERSION ) ack=0 ''
2017.01.05 15:52:03 5: SW: 303b303b333b303b323b0a
2017.01.05 15:52:03 3: MySensorGateway device opened
2017.01.05 15:52:03 3: FB_CALLMONITOR (myFritz) - found 2 phonebooks
2017.01.05 15:52:04 2: FB_CALLMONITOR (myFritz) - read 70 contacts from remote phonebook "Telefonbuch"
2017.01.05 15:52:04 2: FB_CALLMONITOR (myFritz) - read 92 contacts from remote phonebook "Google"
2017.01.05 15:52:04 2: SecurityCheck: WEBphone,WEBtablet has no associated allowed device with basicAuth. telnetPort has no associated allowed device with password/globalpassword. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2017.01.05 15:52:04 0: Featurelevel: 5.7
2017.01.05 15:52:04 0: Server started with 225 defined entities (fhem.pl:12936/2017-01-02 perl:5.014002 os:linux user:fhem pid:6093)
2017.01.05 15:52:05 3: FHEM2FHEM device opened (OUTDOOR7)
2017.01.05 15:52:05 3: FHEM2FHEM device opened (OUTDOOR11)
2017.01.05 15:52:05 3: FHEM2FHEM device opened (Ventilation)
2017.01.05 15:52:05 3: myFritz device opened
2017.01.05 15:52:21 3: Wetter: 0 result(s) retrieved
2017.01.05 15:52:54 5: MYSENSORS send: Rx: fr=001 ci=001 c=001(C_SET ) st=002(V_STATUS ) ack=1 '1'
2017.01.05 15:52:54 5: SW: 313b313b313b313b323b310a
2017.01.05 15:52:54 1: 192.168.178.166:5003 disconnected, waiting to reappear (MySensorGateway)
2017.01.05 15:52:54 5: MYSENSORS send: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=002(I_VERSION ) ack=0 ''
2017.01.05 15:52:54 5: SW: 303b303b333b303b323b0a
2017.01.05 15:52:54 1: 192.168.178.166:5003 reappeared (MySensorGateway)
2017.01.05 15:53:00 5: MYSENSORS send: Rx: fr=001 ci=001 c=001(C_SET ) st=002(V_STATUS ) ack=1 '0'
2017.01.05 15:53:00 5: SW: 313b313b313b313b323b300a
2017.01.05 15:53:00 1: 192.168.178.166:5003 disconnected, waiting to reappear (MySensorGateway)
2017.01.05 15:53:00 5: MYSENSORS send: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=002(I_VERSION ) ack=0 ''
2017.01.05 15:53:00 5: SW: 303b303b333b303b323b0a
2017.01.05 15:53:00 1: 192.168.178.166:5003 reappeared (MySensorGateway)
2017.01.05 15:53:08 5: MYSENSORS send: Rx: fr=001 ci=001 c=001(C_SET ) st=002(V_STATUS ) ack=1 '1'
2017.01.05 15:53:08 5: SW: 313b313b313b313b323b310a
2017.01.05 15:53:08 1: 192.168.178.166:5003 disconnected, waiting to reappear (MySensorGateway)
2017.01.05 15:53:08 5: MYSENSORS send: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=002(I_VERSION ) ack=0 ''
2017.01.05 15:53:08 5: SW: 303b303b333b303b323b0a
2017.01.05 15:53:08 1: 192.168.178.166:5003 reappeared (MySensorGateway)
2017.01.05 15:53:27 3: Wetter: 0 result(s) retrieved
2017.01.05 15:53:57 5: MYSENSORS send: Rx: fr=001 ci=001 c=001(C_SET ) st=002(V_STATUS ) ack=1 '1'
2017.01.05 15:53:57 5: SW: 313b313b313b313b323b310a
2017.01.05 15:53:57 1: 192.168.178.166:5003 disconnected, waiting to reappear (MySensorGateway)
2017.01.05 15:53:57 5: MYSENSORS send: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=002(I_VERSION ) ack=0 ''
2017.01.05 15:53:57 5: SW: 303b303b333b303b323b0a
2017.01.05 15:53:57 1: 192.168.178.166:5003 reappeared (MySensorGateway)
Das Gateway taucht unter bei jedem Umschalten aus FHEM.
lass dich bitte von sonstigen fehler meldungen nicht stören, es handlet sich hiwer um meine FHEM test umgebung und nicht das live system.
gruss
tony
Mal ein blöde Frage, wie ist die Stromversorgung vom Gateway?
Macht der Gateway auch ein Disconnect, wenn Du das
2017.01.05 15:53:08 5: MYSENSORS send: Rx: fr=001 ci=001 c=001(C_SET ) st=002(V_STATUS ) ack=1 '1'
vom MSysController oder per telnet (1;1;1;2;1;) schickst?
das gateway wird von einem externen 9v/1.2A netzteil versorgt.
Nano sitzt auf einem expansion modul mit je einem 3.3v und 5v spannungsregler.
d.h. das WS5100 und das NRF werden nicht direkt vom Nano versorgt.
s.bild (naja noch alpha status, aber für den test ausreichend)
@hjgode: telnet kommt nicht zurück:
Zitat
telnet 192.168.178.166 5003
Trying 192.168.178.166...
Connected to 192.168.178.166.
Escape character is '^]'.
1;1;1;2;1;
gruss
tony
Möglicherweise hängt der Gateway wegen dem ACK in
1;1;1;2;1;
Versuch mal
1;1;0;2;1;
Bei meinem Sensor und Gtaeway habe ich ACK nicht verwenden können. Nachricht wurde vom Gateway nicht verarbeitet. Habe ich nicht weiter verfolgt aber möglicherweise funktioniert ACK nicht richtig in der 2.x API.
auch hier keine reaktion ..
wenn keine lösung in sicht ist, dann heisst es für mich fallback zurück nach 2.0.0.
da hat alles einwandfrei funktioniert.
danke&gruss
tony
Zitat von: hjgode am 05 Januar 2017, 22:22:22
Bei meinem Sensor und Gtaeway habe ich ACK nicht verwenden können. Nachricht wurde vom Gateway nicht verarbeitet. Habe ich nicht weiter verfolgt aber möglicherweise funktioniert ACK nicht richtig in der 2.x API.
Erfahrungswert dazu:
Meine wichtigste Node hat zwei Childs, die mit ACK senden. Das scheint problemlos zu funktionieren (von 2.0.0-beta bis 2.1.0-beta, noch nicht getestet in der finalen Version). Allerdings ist es nicht das (USB-)GW, das die ACKs haben will, sondern die Node.
guten morgen zusammen,
die heiligen 3 könige haben die lösung mitgebracht.
nicht zu glauben, dass es weiterhin an die board-definitionen lag. obwohl das gateway mit dem IDE 1.8.0 nicht mehr in reboot schleife hängt.
jetzt habe ich IDE 1.6.9 verwendet und schau her, es tut alles wieder wie V2.0.0.
einziger unterschid: gateway meldet jetzt "startup complete" anstatt "connected", s.bild.
ich haben auch nicht weiter geprüft, ob die modifikation von Hauswart erforderlich waren - habe die änderungen auch so belassen.
@hjgode: jetzt antwortet auch die telnet abfrage:
Zitat
xxxx@HOMENET:~$ telnet 192.168.178.166 5003
Trying 192.168.178.166...
Connected to 192.168.178.166.
Escape character is '^]'.
1;1;1;2;1;
0;255;3;0;14;Gateway startup complete.
0;255;0;0;18;2.1.0
Connection closed by foreign host.
xxxx@HOMENET:~$ telnet 192.168.178.166 5003
Trying 192.168.178.166...
Connected to 192.168.178.166.
Escape character is '^]'.
1;1;0;2;1;
0;255;3;0;14;Gateway startup complete.
0;255;0;0;18;2.1.0
Connection closed by foreign host.
xxxx@HOMENET:~$
also es gilt weiterhin den hinweis vom Beta-User: Board-Definitionen (<=1.6.11).
ich kann mich bei allen nur herzlich bedanken, grossartiges community.
gruss
tony
Hi tony
erstmal: super dass es bei Dir nun läuft...
Ich möchte ja nicht die Pferde scheu machen, aber ich hoffe Du hast die Verbindung unterbrochen und nicht der Gateway:
xxxx@HOMENET:~$ telnet 192.168.178.166 5003
Trying 192.168.178.166...
Connected to 192.168.178.166.
Escape character is '^]'.
1;1;1;2;1;
0;255;3;0;14;Gateway startup complete.
0;255;0;0;18;2.1.0
Connection closed by foreign host.
Das liesst sich als ob der Gateway nach der Antwort 'aufgelegt' hat! Das wäre nicht korrekt.
~josef
hi Josef,
telnet session wird vom gateway geschlossen.
Was ist noch nicht in ordnung ?
vielen dank
gruss
tony
Wenn das so ist
telnet session wird vom gateway geschlossen.
Wie soll FHEM oder der MSyscontroller oder welcher Controller auch immer denn mit bekommen, wenn einer der Sensoren ein Update sendet, wenn die Verbindung vom Gateway beendet wurde?
Eigentlich ist die Verbindung Controller<->Gateway immer offen (connected, established). Der Controller öffnet bei Start die Verbindung und hält sie bis zu einem gewollten Disconnect offen. Der Gateway vermittelt nun Set oder Get Nachrichten zwischen dem Controller und den Sensoren/Actoren. Wenn der Gateway keine Verbindung zum Controller hat, kann der Sensor zwar an den Gateway senden aber im Controller kommt nix an.
Vielleicht solltest Du Dein Gateway mal seriell anschliessen um zu sehen, was der Code so treibt. Setzen von
#define MY_DEBUG
beim Kompilieren nicht vergessen.
~josef
PS: MYsyController gibts übrigens hier: https://forum.mysensors.org/topic/838/windows-gui-controller-for-mysensors (https://forum.mysensors.org/topic/838/windows-gui-controller-for-mysensors)
hi Josef,
habe ausfürhlich getestet, jede änderung am sensor auch manuell durch den button wird vom FHEM sofort erkannt.
wenn ich den sensor ausschalte und diesen in FHEM triggere, ändert sich der status im FHEM nicht, erst wenn ich den sensor wieder einschalte und acknowledge registriert wird.
für mich siehr alles gut aus und alles funktioniert einwandfrei - vom enduser sicht.
wenn du hier in diesem thread suchst, findest etliche infos, dass der gateway immer den status "startup complete" hat und nicht "connected".
falls du noch das als problem siehst, wäre ich dir für jeden tipp sehr dankbar.
gruss
tony
Hallo tony
wenn ich mich recht erinnere benutzt Du 'nur' einen Switch-Aktor. Das heisst Du sendest ein Nachricht vom Controller (FHEM) and den 'Sensor' (Aktor). Dieser führt den Befehl dann aus. Wenn mit ACK Request an den 'Sensor' gesendet wurde, dann sendet der Aktor dann das ACK zurück.
FHEM scheint die geschlossene Verbindung bei dieser Art der Anwendung nicht zu stören. Es macht einfach die Verbindung wieder auf und sendet den Aktor-Befehl. Dass die Verbindung danach vom Gateway geschlossen wird, scheint FHEM dann nicht zu interessieren (deshalb ja auch meine Bitte um diese periodische Connection-Abfrage an hauswart).
Was aber, wenn Du einen 'echten' Sensor hast. Der Gateway kann keine Verbindung zum FHEM Controller aufbauen, die Verbindung muss von aussen (aus Sicht des Netzwerk-Gateways) kommen. Die Sensordaten sind dann wech.
Hast Du nur den Aktor, dann kann Dir das egal sein. Hauptsache es läuft für Dich. Wundere Dich dann nicht über evtl. wechselnde Connected/StartupComplete/Disconnected Stati Deines Gateways in FHEM.
Übrigens macht mein ESP8266-Mysensors Gateway die Connection bei Telnet nicht von sich aus zu. Möglicherweise liegt das an der Netzwerk-Implementierung das w5100-Gateways. Der W5100 kann zB wohl nur einen Client bedienen:
// W5100/ENC module does not have hasClient-method. We can only serve one client at the time.
EthernetClient newclient = _ethernetServer.available();
// if a new client connects make sure to dispose any previous existing sockets
if (newclient) {
if (client != newclient) {
client.stop();
client = newclient;
Wenn Du also mit FHEM und Telnet verbinden willst, wird die jeweils andere Verbindung gekappt.
Wie gesagt, wenn's bei Dir läuft, super.
~josef
hi Josef,
nicht nur relay aktor, alles noch testphase.
habe auch mit motion und dht22 sensoren getestet. alles sieht wirklich perfekt aus.
daten flattern sauber rein.
FHEM - gateway - sensoren unterhalten sich wie es sein soll.
ich kann momentan kein problem erkennen, ich teste aber weiter - auch andere sensoren - und berichte dann.
nochmal besten dank
gruss
tony
Dann will ich mal auch noch meine aktuelle Erfahrung wiedergeben.
Ich nutze für mein WiFi Gateway aktuell einen Wemos Mini mit SMD NRF24L01+PA+LNA Modul.
Folgende Software Versionen nutze ich:
Arduino IDE: 1.8.0
ESP Version: 2.3.0
Arduino AVR Boards: 1.6.16
MySensors: 2.1.0
Ich habe mit dem Gateway absolut keine Probleme. Alle Sensoren werden sauber empfangen.
Bei den Sensoren nutze ich aktuell noch unterschiedliche MySensors Versionen. (1.5.4, 2.0, 2.1.0 Beta, 2.1.0)
Aktuell hätte ich auch noch ein solches Gateway abzugeben.
Ich denke mal, die Probleme mit dem Ethernet-Gateway sind darin begründet, das er nur einen Ethernet-Client bedienen kann. Sobald sich ein zweiter Client über Port 5003 verbindet, wird der aktuelle Client getrennt.
Wenn nun FHEM als MySensors Controller läuft und sonst kein zweiter 'Controller' eine Verbindung zum Port 5003 des Gateways öffnet, läuft alles. Wenn man dann aber anfängt zu testen, während FHEM läuft, zum Beispiel eine Telnet Session oder MySyscontroller mit dem Gateway verbindet, wird die FHEM Verbindung getrennt werden. Wenn ich dann, zB, mit Telnet eine Nachricht an den Controller sende und dann aber FHEM die Verbindung im Hintergund wieder aufbaut, wird die Telnet-Session vom Controller getrennt.
Anders kann ich mir das derzeit nicht erklären.
Ich hatte damals schon zu viele Probleme mit dem ENJ Ethernet Teil (AVR-Net-IO) und dann auch mit dem W5100 als das ich jetzt Lust hätte die wieder rauszukramen. Mit dem ESP8266 kann ich FHEM, Telnet und MySyscontroller gleichzeitig auf das MySensors-Gateway verbinden. (Obwohl ich da auch seltsame versteckte FHEM Disconnects hatte und deshalb die DevIO.pm und 00_MySensors.pm angepasst habe damit das erste Keep_Alive nicht nach zwei Stunden für die FHEM Verbindung kommt und zum anderen in FHEM ersichtlich ist, ob der Gateway noch aktiv verbunden ist-das sieht man jetzt nämlich nicht).
~Josef
Ich klink mich auch mal kurz hier ein. Nutze selber den Hexenmeister Gateway aber mit aktueller Firmware (Beta). Auch dieser kann nur EINE Verbindung zur Zeit, allerdings kann ich z.B. wenn die Verbindung zum FHEM besteht NICHT einfach mit MYSController verbinden das klappert nicht. Ich muss erst FHEM trennen und dann funzt MYSController.
das ist ja ein grosse schwachsinn mit dem ethernet gateway, war gedacht als zentrals gateway und von überall zugreifbar z.bsp. test parallel zu live FHEM umgebung.
folgendes habe ich gearde getestet:
alle meine beiträge oben haben sich in der test umgebung abgespielt.
jetzt wollte ich testen, ob das WS5100 nur ein session erlaubt. dafür habe ich das gateway 1:1 im parallel betrieb mit der live umgebung verbunden.
gateway status in beiden FHEM instanzen flackert rasant zwischen "disconnected" und "connected" und keins von beiden systemen kann mit dem gateway saubere verbindung aufbauen.
trenne ich es aber von einer FHEM instanz dann läuft es problemlos.
ich frage mich dann, welche vorteile hat das ethernet gateway gegenüber seriell !!!???
tony
Ethernet kann halt ÜBERALL in deinem Netzwerk sein, der Serielle muss halt an den Seriellen Port.
Hallo zusammen
noch mal zusammengefasst:
Der MySensors Ethernet Gateway unterstützt nur eine aktive Netzwerk-Verbindung. Dies liegt aber nicht am W5100 (ENJ habe ich noch nicht recherchiert). Der W5100 kann max 4 Verbindungen. Es liegt an der Arduino Ethernet Library.
Referenzen: https://github.com/mysensors/MySensors/issues/398 und https://forum.mysensors.org/topic/3114/other-controller-get-disconnected-when-sending-any-command-to-the-eth-gateway-v2-0/12
MySensors development schiebt das 'Problem' an die Ethernet Lib Entwickler.
Als Alternative oder Workaround kann man zum MySenors MQTT Gateway wechseln. Der MQTT Gateway kommuniziert nur mit dem MQTT Broker und alle 'Clients' (besser: Controller, FHEM etc) kommunizieren über den Broker mit dem Gateway. Es gibt also nur eine Netzwerk-Verbindung vom MQTT-MySensors Gateway zum Broker und beliebige MQTT Abonnenten dazu.
~Josef
danke Josef für die wertvollen infos.
eine frage noch:
eine weitere lan verbindung braucht man z.bsp wenn sich test/live FHEM instanzen oder FHEM/myscontroller das gateway teilen.
bei welchen szenarien braucht man noch gleichzeitig mehr als eine lan verbindung zum gateway ?
gruss
tony
Hallo tony
also normalerweise braucht man nur eine Verbindung Gateway<->Controller.
Wenn Du 'nur' ein 'normales' serielles Gateway hättest, kann da normalerweise (multplexing mal aussen vor) nur ein 'Controller' dran.
Alles andere sind eigentlich Sonderfälle: test und produktiv Umgebung gleichzeitig, debugging, telnet tests...
~josef
Hat jemand eine Idee wo die Probleme herkommen?
2017.01.09 21:07:34 3: MYSENSORS: ignoring set-msg from unknown radioId 200, childId 1 for V_TEMP
2017.01.09 21:07:35 3: MYSENSORS: ignoring set-msg from unknown radioId 200, childId 2 for V_HUM
2017.01.09 21:07:35 3: MYSENSORS: ignoring set-msg from unknown radioId 200, childId 199 for V_VOLTAGE
2017.01.09 21:07:35 3: MYSENSORS: ignoring internal-msg from unknown radioId 200, childId 255 for I_BATTERY_LEVEL
Edit: Problem gelöst. Irgendwie hatte ich das Gateway zweimal angelegt.
Falsches IODev (Gateway) beim Sensor konfiguriert bzw. mehr als ein Gateway empfängt die Daten des Sensors und gibt sie weiter.
Es ist wohl in Fhem vorgeschrieben, über welches Gateway ein Sensor seine Daten an die Zentrale geben soll/darf.
Dem Gateway hingegen ist es egal, von welchem Sensor die Daten kommen, es es gibt einfach alles weiter.
Da bräuchte man mal ein virtuelles Gateway, wie bei Homematic....
Bzw. eine Logik, die doppelte Nachrichten erkennt und aussortiert.
weiß jemand, ob der Befehl "smartSleep" in Fhem funktioniert? D.h. in regelmäßigen Abständen holt sich ein Sensor seine Nachrichten/Befehle beim Gateway ab.
SmartSleep hat nix mit FHEM zu tun, ist ein MySensors eigener Befehl und regelt nur das verhalten zwischen Gateway und Sensor.
Bin mir da nicht so sicher... andere Controller (Software) "können" SmartSleep - oder auch nicht, siehe hier: https://www.mysensors.org/controller
Bei smartsleep meldet sich der Node kurz vor dem Schlafen beim Controller und dieser kann in einem Zeitfenster noch Messages zum Node schicken.
FHEM kann das (noch) nicht. Leider :-[.
Das bedeutet nur das der Sensor oder Aktor noch etwas Zeit vertrödelt bevor er sich schlafen legt = sleep , bei Mysensors heißt es dann Smartsleep und lauscht halt noch einige Zeit im Funk ob da noch was vom Gateway kommt (z.B. "starte OTA Update"). Und DAS kann FHEM zur zeit noch nicht also noch extra Befele senden.
Hallo,
Sind Projekte bekannt für MySensors wo an einem Arduino mehrere Sensoren angeschlossen werden?
z.B. mehrere MQ-xx DS18B20 ( zur kompensation ) usw.
Den normalerweise ist ja bei MySensors pro Arduino ein Sensors vorgesehen, oder sehe ich das falsch?
Ja das siehst du falsch. Du kannst ohne Probleme mehrere Sensoren an einen Arduino anschließen.
Hier gibt es auch ein Sample dazu:
https://forum.mysensors.org/topic/1393/2-or-more-dht11-sensors-on-one-arduino-nano-mysensor/9 (https://forum.mysensors.org/topic/1393/2-or-more-dht11-sensors-on-one-arduino-nano-mysensor/9)
Ist zwar noch mit der alten MySensors Bibliothek aber ich denke die Vorgehensweise sollte ersichtlich sein.
Hat eigentlich schon jemand hier Erfahrung mit RS485-Verbindungen statt Funk? Hätte den Charme, dass man die Flexibilität von MySensors verbinden kann mit einer Kabelverbindung bei Verwendung von nur 2-3 Adern ;) .
@Edi77: Im Wiki-Starter-Guide gibt es dazu auch einen Link wie die Vorgehensweise zur Erweiterung einer Node mit weiteren Sensoren ist. Mehrere DS 18B20 gehen übrigens auch mit dem Standard-Sketch ;D .
MOD-EDIT:
RS485-Diskussion nach hierher (https://forum.fhem.de/index.php/topic,74670.0.html) abgetrennt...
Erfahrungen nicht, aber die HW zu Hause und schon länger geplant wichtige Sensoren so anzubinden.
Gesendet von meinem HTC One_M8 mit Tapatalk
Hallo!
Ich habe ein MySensors Device in Fhem mit einem Userreading deklariert.
Wie kann ich nun mit dem webcmd Befehl dieses Userreading ändern?
Z.B hab ich in einem MySensor-Gerät das Userreading "inhalt" geschrieben.
Nun würde ich gern in der Weboberfläche 2 Schaltflächen haben ,die "leer" oder "voll" in's Userreading schreiben.
Kann man das so irgendwie machen, ohne ein weiteres Dummy-Device deklarieren zu müssen?
Hallo thunder1902,
was genau willst Du mit der Lösung bezwecken? Ein Reading will man ja üblicherweise nicht schalten, oder?
Wenn Du auf einzelne Children direkt zugreifen willst, dürften eher readingsproxy, widgetoverride oder webcmd in Frage kommen.
Grüße, Beta-User
Hallo zusammen,
ich hole diesen Thread mal wieder nach oben. Ich habe zwei SensebenderMicro und der eine hat sporadisch Aussetzer. Komischerweise sendet der aber wieder, wenn ich kurz die Versorgungsspannung aus- und wieder einschalte.
M.Wn. gibt es keinen RSSI Wert, den man mitloggen könnte, aber mein Verdacht ist, dass es sich ggf. um ein Reichweitenproblem handeln könnte. Momentan geht der Sensor, der sporadisch ausfällt über zwei Stockwerke, der andere nur über eines. Habt Ihr irgendwelche Ideen, wie bzw. wo ich mit der Suche ansetzen könnte?
Danke + Gruß
PeMue
@PeMue:
Wenn es nicht zu viel Aufwand drumrum verursacht: versuch's mal mit der aktualisierten Board-Def.
Aber Achtung: die neuen RF-Treiber brauchen mehr Strom, kann uU. also kontraproduktiv sein...
Ich hatte mal einen ähnlichen Effekt. Der kam aber vom WLAN-Router (TPlink Powerline).
Der Fhem Server hat per Broadcast nach der arp Adresse des Mysensors Gateways gefragt, aber nicht immer eine Antwort bekommen. Ich habe das zufällig entdeckt und mal die arp händisch beim Server gesetzt. Daraufhin funktionierte/pingte es wieder. Seit dem mache ich regelmäßig ein Ping auf das Gateway, damit sich der arp cache der Servers aktualisiert.
Gesendet von meinem Toaster.
Zitat von: micky0867 am 24 März 2017, 15:13:13
Der Fhem Server hat per Broadcast nach der arp Adresse des Mysensors Gateways gefragt, aber nicht immer eine Antwort bekommen.
Danke für den Hinweis. Ich denke, beim seriellen Gateway sollte das aber nicht relevant sein.
Gruß PeMue
Hallo zusammen,
ich bin neulich endlich mal wieder dazu gekommen mich mit der Reichweite des IR Senders/Empfängers näher zu beschäftigen.
Vielleicht interessiert es ja noch jemanden....
Ich habe die Schaltung im Anhang aufgebaut. LEDs sind bei mir aber TSAL6200 von Vishay.
Funktioniert einwandfrei. Egal wo und in welche Richtung der Sender im Wohnzimmer steht, die Geräte schalten zuverlässig.
Yamaha Receiver und BenQ Beamer gehen 1A. Den Empfänger meines HDMI Switches muss man sehr nah ran halten. Ist ein total gammeliger Empfänger verbaut.
Geht mit der original Fernbedienung auch nicht besser. Den tausche ich noch gegen einen TSOP1738. Damit sollte es besser werden.
Mit der VU+ Uno geht es noch gar nicht. Die nutzt so einen blöden RC6 Toggle Code. Habe bei Remotecentral zwar diskrete Codes für On und Off gefunden, allerdings im Pronto Hex Code und ich konnte die noch nicht konvertieren.
Nach Suche hier im Thread ist mir nicht klar, wo der aktuellste Stand der Module 10_MYSENSORS_DEVICE.pm und 00_MYSENSORS.pm zu finden ist.
Das Repository von @ntruchsess (https://github.com/ntruchsess/fhem-mirror/tree/master/fhem/FHEM (https://github.com/ntruchsess/fhem-mirror/tree/master/fhem/FHEM)) und das SVN-Repo von FHEM (https://svn.fhem.de (https://svn.fhem.de)) sind auf dem gleichen Stand (02.10.2015 und 29.02.2016). Sie enthalten aber vermutlich nicht alle Patches etc. aus diesem Thread. Gibt es einen neueren getesteten Stand der insbesondere zu MySensors 2.1.1 passt?
Gruß,
Mario
@Mario:
Soweit ich den Überblick nicht verloren habe, ist der aktuellste Stand hier zu finden:
https://raw.githubusercontent.com/Kolbi/fhem-mirror/Kolbi-patch-2/fhem/FHEM/00_MYSENSORS.pm
https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/10_MYSENSORS_DEVICE.pm
https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/lib/Device/MySensors/Constants.pm
So jedenfalls auch die Analyse der pull-Requests in norberts Repo auf Github: https://github.com/ntruchsess/fhem-mirror/pulls.
M.E. sollten alle drei Dateien getauscht werden.
An sich funktionieren aber auch die "alten" bis auf eher kosmetische Dinge, wenn man vom Löschen ganzer GW's mal absieht. Die neuen Features seitens 2.1.1 werden aber in keiner der Versionen unterstützt.
Gruß, Beta-User
Danke, ich werde heute Abend aufräumen und wieder in Betrieb nehmen.
Gibt es keinen maintainer mehr, der die Module "wartet"?
Wenn Norbert nicht mehr aktiv ist, sollte das evtl ein anderer Übernehmen..
Hallo,
Ich suche schon eine ganze Weile, wie kann man die Signalstärke von einem Sensor auswerten, bzw. wie man die Reichweite testen kann?
Habe momentan ein ESP8266 Gateway, will aber jetzt ein ESP8266<>RFM95 Gateway testen.
Das kennste schon?
Direkt Feldstärke sieht man nicht, aber ab welcher Entfernung die Übertragung unzuverlässig wird.
https://forum.mysensors.org/topic/3984/nrf24l01-connection-quality-meter (https://forum.mysensors.org/topic/3984/nrf24l01-connection-quality-meter)
DANKE @KarlHeinz2000
Kannte ich noch nicht, sollte sich aber auch auf RFM69 & RFM95 umrüsten lassen.
Probleme mit RFM69 & RFM95
Ich habe mal ein Gateway mit einem RFM 95 gebaut.
Getestet mit richtiger Antenne und Drahtantenne ( 86mm )
0;255;3;0;9;397 TSF:LRT:OK
0;255;3;0;9;425 TSM:INIT
0;255;3;0;9;451 TSF:WUR:MS=0
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 2
cnt
connected with AP1, channel 13
dhcp client start...
0;255;3;0;9;624 TSM:INIT:TSP OK
0;255;3;0;9;656 TSM:INIT:GW MODE
0;255;3;0;9;690 TSM:READY:ID=0,PAR=0,DIS=0
0;255;3;0;9;735 MCO:REG:NOT NEEDED
f r0, scandone
....ip:192.168.1.234,mask:255.255.255.0,gw:192.168.1.1
.IP: 192.168.1.234
0;255;3;0;9;3273 MCO:BGN:STP
0;255;3;0;9;3323 MCO:BGN:INIT OK,TSP=1
pm open,type:2 0
Sieht ja schon mal gut aus.
Dann habe ich einen Sensor gebaut z.B. Motion
Allerdings verbindet der sich nicht.
0 MCO:BGN:INIT NODE,CP=RPNNA---,VER=2.2.0-beta
49 TSM:INIT
51 TSF:WUR:MS=0
53 TSM:INIT:TSP OK
55 TSM:FPAR
59 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2068 !TSM:FPAR:NO REPLY
2070 TSM:FPAR
2074 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
4083 !TSM:FPAR:NO REPLY
4085 TSM:FPAR
4089 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
6100 !TSM:FPAR:NO REPLY
6103 TSM:FPAR
6107 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
8116 !TSM:FPAR:FAIL
8118 TSM:FAIL:CNT=1
8120 TSM:FAIL:DIS
8122 TSF:TDI:TSL
Ich habe das mit Version 2.1.1 und 2.2.0 beta getestet, auch mir RFM69, brachte alles nichts.
Hat jemand eine Idee
-kommen die Debug Ausgaben auf beiden Geräten mit 115.200 Baud ? (Wenn nicht ist der Takt keine 16MHz)
Gateway hat 9.600 der Arduino 115.200
Hallo guten Morgen,
weiss einer von euch "wohin" das mysensorsmodul seine Dateien schreibt ?
Also mein konkretes Problem ist folgendes.
Wenn ich ein Node am FHEM anmelde bekommt es ja eine ID zugeteilt und diese ID ist dann quasi verbraucht und wird auf immer und ewig diesem Node zugeteilt bleiben.
Auch nach einem Löschen der Node im FHEM und EEPROM-Wipe der Node geht der Counter im FHEM eins nach oben bei erneutem verbinden.
Ich hoffe ich habe das irgendwie verständlich erklärt...
Danke und Gruss
Komaandy
Guten Morgen Komaandy,
der code von 00_mysensors.pm (ab line 361) scheint das dynamisch auszuwerten.
Aber was hindert Dich daran, die NodeID per Sketch so zu vergeben, dass "verwaiste" NodeIDs wieder sinnvoll mit Leben gefüllt werden? Dann kannst Du Dir den EEPROM-Wipe auch sparen ;) .
Ich mache das nur noch so, dass die ID's in allen Sketchen manuell vergeben sind (bei RS485 ist das eh' Pflicht). Hatte sich aber auch in der nRF24-Welt bewährt, da man dann die Arduinos bedenkenlos beim Entwickeln hin- und hertauschen kann.
Gruß, Beta-User
Hallo, danke für die Antwort erstmal.
Die Node_ID vergeben ich schon statisch, aber ich meine den Effekt beobachtet zu haben dass FHEM die ID eben nur einmal zulässt.
Also ich vergebe z.B. die Node_ID 34, die Node meldet sich am FHEM an, ich lösche die Node und kann Sie dann nicht noch einmal neu anmelden unter der 34, sondern muss per Sketch eine neue ID vergeben bevor FHEM es wieder akzeptiert.
Gruss
Komaandy
Hi Komaandy,
das von Dir beschriebene Verhalten wäre mir neu, MySensors kam mir in diese Richtung bislang eher immer sehr (fast zu) tolerant vor.
Bist Du sicher, dass inclusion mode und autocreate an sind und ansonsten auch die Kommunikation zwischen FHEM und der Node funktioniert (serielle Konsole der Node beobachten)?
Es kann nur uU. etwas dauern, bis alle Readings da sind.
Gruß, Beta-User
Also das letzte Problem habe ich nun gelöst, ich habe das Verhalten tatsächlich falsch beobachtet...
Jetzt habe ich aber eine neue Herrausforderung. Eine meiner Nodes hat einen Sketch mit Bewegungsmelder der aber nur ein ON sendet und kein OFF. Das Reading updatet sich einfach immer mit dem Timestamp des letzten Auslösens. (->Damit könnte man auch arbeiten, wenn ich quasi ein Notify erstelle, dass auslöst wenn sich der Timestamp des readings ändert. Aber keine Ahnung wie...<- )
Bevor ich mir jetzt den Sketch total verbastel hoffe ich einfach, dass ich einen weg finde den Status des Nodes direkt im FHEM nach sagen wir mal 5 Sekunden wieder auf OFF zu setzen.
Mit setstate wird ja leider kein Event ausgelöst und einen anderen Weg finde ich per google einfach nicht :(
Danke und Gruss
Komaandy
Die PIRs haben normalerweise 2 Potis, einer für Empfindlichkeit und einer für die Dauer des High-Signals.
Gesendet von meinem ONEPLUS A3003 mit Tapatalk
Ja das stimmt, es ist nur so, der Sketch den ich auf dem Arduino verwende ist wirklich gut und deckt alles ab was ich brauche.
Dummerweise ist in diesem Sketch einfach nicht angelegt dass der Arduino das LOW-Signal ans FHEM meldet.
Dieser Sketch wird von den meisten mit Domoticz verwendet und die behelfen sich dort einfach mit einem "Autoreset" des Status direkt im Domoticz...
Aber eben, diesen "Autoreset" bekomme ich im FHEM nicht realisiert...
Hi,
Mach doch ein notify, das auf on reagiert mit sleep5; set dev off ;-)
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
@RaspiLED
das hab ich auch schon versucht , aber es funktioniert so leider nicht...
MYSENSOR_44:tripped5:.on sleep 5 ; set MYSENSOR_44 off
Zuviele leerzeichen und die semikolons verdoppeln ;-)
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Hallo zusammen,
ich bin mir nicht 100% sicher, ob dies hier der richtige Ort ist, aber es sieht für mich nach dem MySensors-Sammelthread aus... :)
Ich wollte mal fragen, ob jemand das gleiche Problem beobachtet hat, wie ich:
Undzwar nutze ich MySensors um Temperaturdaten von OneWire-Sensoren mit 433MHz-Nodes/Gateway (Adafruit Feather M0 ATSAMD RFM69HCW) per seriellem USB an FHEM auf einem RPi 3 Typ B zu übertragen.
Das funktioniert auch ganz wunderbar mit ein paar Anpassungen. Die Sketche sind auf Node-Seite leicht angepasst für einen Sleepmode (den gibt es in der MS-Version noch nicht von Haus aus für SAMD-Chips) und auf der Gateway-Seite eigentlich unverändert.
ABER: Die Übertragung funktioniert einige Zeit (1-2 h) und bricht dann aus nicht nachvollziehbaren Gründen ab. Ich bin gerade am rumforschen, wo der Fehler zu finden ist. Für mich sieht es so aus, als würde das Node auf jeden Fall noch senden. Gateway kann ich morgen überprüfen. Ich habe leider noch keinen Weg gefunden den USB-Port auf dem Pi während FHEM läuft mitzulesen (Windows-Kind).
Vielleicht kennt jemand dieses Problem ja aber schon und kann mir kurz auf die Sprünge helfen?
Sollte ich mit Informationen zu geizig sein, werde ich diese natürlich gerne nachliefern. Ich weiß nur noch nicht, was dabei heiße News und was ein alter Hut ist.
Vielen Dank und beste Grüße!
Hi, stell doch in FHEM im Gateway den verbose auf 5 und schau mal was das FHEM.log freiwillig im Browser sagt.
Welchen Status/State hat Dein Gateway am Anfang und an Ende?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Hallo habe ein Problem beim Sender von IR-Signalen, empfangen klappt !
set MYSENSOR_16 ir_send1 1 0xC1AA09F6 32, NEC
bekomme in FHEM die Meldung:
ir_send1 not defined: no mapping for reading ir_send1
Was mache ich falsch ?
FHEM ist aktuell und der Sketch ist:
/**
The MySensors Arduino library handles the wireless radio link and protocol
between your home built sensors/actuators and HA controller of choice.
The sensors forms a self healing radio network with optional repeaters. Each
repeater and gateway builds a routing tables in EEPROM which keeps track of the
network topology allowing messages to be routed to nodes.
Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
Copyright (C) 2013-2015 Sensnology AB
Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors
Documentation: http://www.mysensors.org
Support Forum: http://forum.mysensors.org
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
version 2 as published by the Free Software Foundation.
*******************************
REVISION HISTORY
Version 1.0 - Henrik EKblad
Version 1.1 - rknipp and rejoe2
Version 1.1.1 - rknipp
DESCRIPTION
Example sketch showing how to control ir devices
An IR LED must be connected to Arduino PWM pin 3.
An optional ir receiver can be connected to PWM pin 8.
All received ir signals from PIN 8 will be sent to gateway device stored in IR_RECEIVED.
NEW: The Node expects real IR commands to process via the IR_SEND variable (instead of "on/off" via V_LIGHT).
Variable format to be sent form controller side is: "protocol code irbits", eg. "1 0x1EE17887 32"
for Vol up yamaha ysp-900 (assuming NEC-codes are mapped to protocol #1 in your IRLib).
IMPORTANT:
The IRLib used here is Gabriel Staples version available at https://github.com/ElectricRCAircraftGuy/IRLib,
so IR commands are different from the standard IRLib delivered with MySensors!
http://www.mysensors.org/build/ir
*/
// Enable debug prints
#define MY_DEBUG
#define USE_DUMP //should print out lots of info to serial (ElectricRCAircraftGuy feature?)
// Enable and select radio type attached
//#define MY_RADIO_NRF24
#define MY_RADIO_RFM69
#define MY_IS_RFM69HW
//#define MY_RFM69_ENABLE_ENCRYPTION
//#define MY_RFM69_NETWORKID 100 // Default is 100 in lib. Uncomment it and set your preferred network id if needed
#define MY_RFM69_TX_POWER_DBM 20 // 5-20 dB
#define MY_BAUD_RATE 38400
#define MY_NODE_ID 16
#include <SPI.h>
#include <MySensors.h>
#include <IRLib.h> //Gabriel Staples version!
int RECV_PIN = 8;
#define CHILD_ID_IR 1 // childId
IRsend irsend;
IRrecv My_Receiver(RECV_PIN);
IRdecode My_Decoder;
MyMessage msgIr(CHILD_ID_IR, V_IR_RECEIVE);
void setup()
{
// My_Decoder.useDoubleBuffer(Buffer); //uncomment to use; requires the "extraBuffer" to be uncommented above
//Try different values here for Mark_Excess. 50us is a good starting guess. See detailed notes above for more info.
My_Receiver.Mark_Excess = 50; //us; mark/space correction factor
//Optional: set LED to blink while IR codes are being received
// My_Receiver.blink13(true); //blinks whichever LED is connected to LED_BUILTIN on your board, usually pin 13
// //-see here for info on LED_BUILTIN: https://www.arduino.cc/en/Reference/Constants
My_Receiver.setBlinkLED(13, true); //same as above, except you can change the LED pin number if you like
My_Receiver.enableIRIn(); // Start the receiver
}
void presentation() {
// Send the sketch version information to the gateway and Controller
sendSketchInfo("IR Sensor", "1.1.1");
// Register the sensor als IR Node
present(CHILD_ID_IR, S_IR);
}
void loop()
{
if (My_Receiver.getResults(&My_Decoder)) //if IR data is ready to be decoded
{
//1) decode it
My_Decoder.decode();
Serial.println("decoding");
Serial.print("Protocol:");
Serial.print(Pnames(My_Decoder.decode_type));
Serial.print(",");
Serial.print(My_Decoder.decode_type);
Serial.print(" ");
Serial.print(My_Decoder.value, HEX);
Serial.print(" ");
Serial.println(My_Decoder.bits);
//FOR EXTENSIVE OUTPUT:
//My_Decoder.dumpResults();
//filter out zeros for not recognized codes and NEC repeats
const char rec_value = My_Decoder.value;
if (rec_value != 0xffffffff && rec_value != 0x0) {
char buffer[24];
uint8_t IrBits = My_Decoder.bits;
String IRType_string = Pnames(My_Decoder.decode_type);
char IRType[IRType_string.length() + 1];
IRType_string.toCharArray(IRType, IRType_string.length() + 1);
sprintf(buffer, "%i 0x%08lX %i, %s", My_Decoder.decode_type, My_Decoder.value, IrBits, IRType);
// Send ir result to gw
send(msgIr.set(buffer));
#ifdef MY_DEBUG
//2) print results
//FOR BASIC OUTPUT ONLY:
Serial.println(buffer);
#endif
}
//3) resume receiver (ONLY CALL THIS FUNCTION IF SINGLE-BUFFERED); comment this line out if double-buffered
/*for single buffer use; do NOT resume until AFTER done calling all decoder
functions that use the last data acquired, such as decode and dumpResults; if using a double
buffer, don't use resume() at all unless you called My_Receiver.detachInterrupt() previously
to completely stop receiving, and now want to resume IR receiving.*/
My_Receiver.resume();
}
}
void receive(const MyMessage &message) {
const char *irData;
// Complete send command from controller side is needed, e.g. "1 0x1EE17887 32"
if (message.type == V_IR_SEND) {
irData = message.getString();
#ifdef MY_DEBUG
Serial.println(F("Received IR send command..."));
Serial.println(irData);
#endif
int i = 0;
char* arg[3];
unsigned char protocol;
unsigned long code;
unsigned int bits;
char* irString = strdup(irData);
char* token = strtok(irString, " ");
while (token != NULL) {
arg[i] = token;
token = strtok(NULL, " ");
i++;
}
#ifdef MY_DEBUG
Serial.print("Protocol:"); Serial.print(arg[0]);
Serial.print(" Code:"); Serial.print(arg[1]);
Serial.print(" Bits:"); Serial.println(arg[2]);
#endif
protocol = atoi(arg[0]);
code = strtoul(arg[1], NULL, 0);
bits = atoi(arg[2]);
irsend.send(protocol, code, bits);
free(irString);
}
// Start receiving ir again...
My_Receiver.resume();
}
Kannst du noch die Definition von MYSENSOR_16 posten? Hast du den Sensor mit der aktuellsten FHEM-Version via autocreate definieren lassen?
Hallo,
vielen Dank für die Unterstützung.
Dieses wurde mit aktuellem FHEM automatisch angelegt:
define MYSENSOR_16 MYSENSORS_DEVICE 16
attr MYSENSOR_16 IODev mySensors
attr MYSENSOR_16 mapReading_ir_receive1 1 ir_receive
attr MYSENSOR_16 mode node
attr MYSENSOR_16 setReading_ir_send1 1
attr MYSENSOR_16 version 2.1.1
setstate MYSENSOR_16 2017-10-09 14:48:00 SKETCH_NAME IR Sensor
setstate MYSENSOR_16 2017-10-09 14:48:00 SKETCH_VERSION 1.1.1
setstate MYSENSOR_16 2017-10-09 16:40:33 ir_receive1 1 0xC1AA09F6 32, NEC
setstate MYSENSOR_16 2017-10-09 15:23:51 parentId 0
Schade, dass ich bisher keinen IR-Sensor habe :) Komponenten hatte ich mir mal bestellt, aber keine Zeit bisher gehabt.
Ich werde nachher mal testen, ob ich es nachstellen kann. Jedoch wundert mich, wieso ir_record als mapReading fehlt. Kannst du eventuell das Device ganz löschen? Speichern + Update + FHEM restart und das nochmal neu anlernen?
Workaround:
Teste mal folgendes: attr MYSENSOR_16 mapReading_ir_send1 1 ir_send und berichte.
Hallo,
das war es :-)
Klappt prima jetzt, vielen Dank !
Habe kurzerhand alle setReading auch als mapReading definiert, macht auch Sinn zu sehen, welches der letzte Befehl war, welcher an das Device gesendet worden ist. Morgen im Update.