Node findet Gateway nicht

Begonnen von The Grue, 03 Dezember 2017, 19:30:43

Vorheriges Thema - Nächstes Thema

The Grue

Servus,

gerade bin ich dabei, das erste Gateway mit Node zu bauen, aber der Node findet das Gateway nicht. Ich habe schon im MySensorsForum geposted, aber weil ich nicht sicher bin auf welcher Seite der Fehler liegt, bitte ich Euch, mal hier vorbei zu schauen:

https://forum.mysensors.org/topic/8670/gateway-receives-brocast-but-node-fails-to-find-parent

Vielen Dank,
Markus

Ranseyer

Die finden nicht zusammen. Kennst Du den Logfileparser ? https://www.mysensors.org/build/parser

PS: Als ersten Sensor würde ich immer "Motion" nehmen, der braucht gar keinen Sensor und meldet dann einfach pausenlos "tripped", also ausglöst...
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

The Grue

Hallo Ranseyer,

ja, den Parser habe ich schon mit diesen Ausgaben gefüttert. Leider hilft mir das nicht bei der Suche nach der Ursache...

Mit dem Motion-Sensor wirst Du Recht haben, aber ich hätte halt gern schon was, das ich in FHEM integrieren kann - quasi schon mal sehen, daß "round-trip" vom Sensor über's Gateway in FHEM funktioniert...

Danke für Deine Anregung!
Markus

Ranseyer

Hm, wir könnten mal ein Beispiel posten wie es aussieht wenn der Controller (=FHEM) fehlt...
Aber in deinem Fall würde ich mal bei groben Lesen behaupten gar keine Kommunikation. Das wäre also noch vor dem Bedarf einen Controller zu haben.

Ich bin gerade auch am experimentieren. Evtl. kann ich die Tage mal 1-2 Beispiele von Problemen erzeugen...
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Beta-User

Hallo Markus,

auf MySensors.org kam das irgendwie nicht so klar raus:

Du hast in FHEM autocreate (global oder auf das GW bezogen) eingeschaltet (Includion mode am GW war ja "on", oder verstehe ich den Post falsch)?

Ansonsten: wie weit sind GW und Node voneinander entfernt?

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

The Grue

Servus zusammen,

Wochenende, endlich Zeit zum Fehlersuchen :/ Würde ja lieber Sensoren bauen...

Schon mal vielen Dank für Eure Hinweise! Im MySensors-Forum herrscht ja totales Schweigen :(

Also zu Euren Fragen:
Zitat
Aber in deinem Fall würde ich mal bei groben Lesen behaupten gar keine Kommunikation.

Das glaube ich nicht, weil:


  • Ich stecke das Gateway an USB+Ethernet
  • FHEM schreibt ins log: 2017.12.09 12:26:02 1: 192.168.178.3:5003 reappeared (MySensors.Gateway)
    Kommunikation via Ethernet geht also schon mal (war aber, glaube ich, auch nicht was Du meintest...)
  • Auf ttyUSB0 sehe ich die Initialisierung des Gateways. Ich warte etwas ab, bis sich hier nichts mehr tut.
  • Ich schalte den Sensornode ein
  • Sofort tut sich was im Log des Gateways und das immer wieder, solange der Sensor eingeschaltet ist (WAS sich da tut habe ich oben schon gepostet). Also: Der Sensor sendet etwas und das Gateway empfängt auch etwas -> Kommunikation in mindestens einer Richtung

Ich vermute ganz naïv, weil ich von MySensors keine Ahnung habe: Das Gateway kommt nicht in den Inklusionsmodus. Das Gateway aus Sicht von FHEM:

defmod MySensors.Gateway MYSENSORS 192.168.178.3:5003
attr MySensors.Gateway autocreate 1
attr MySensors.Gateway room Maschinenraum
attr MySensors.Gateway stateFormat connection

setstate MySensors.Gateway connected
setstate MySensors.Gateway 2017-12-09 12:26:02 connection connected
setstate MySensors.Gateway 2017-12-09 12:26:02 state opened


@Beta-User: Autocreate ist also IMHO an. Gateway und Sensor sind ca. 20cm voneinander entfernt. Sie waren noch nie weiter als 50cm getrennt...

Ich versuche also, das Gateway in den Inklusionsmodus zu setzen:

Erst mal abschalten, nur um sicher zu gehen, daß der Modus nicht schon aktiv ist:

set MySensors.Gateway inclusion-mode off


Im Eventlog:
Zitat
2017-12-09 12:48:23 MYSENSORS MySensors.Gateway inclusion-mode off

Im Log auf ttyUSB0 tut sich nichts. Im FHEM-Log auch nicht.

Dann:

set MySensors.Gateway inclusion-mode on


Im Eventlog:
Zitat
2017-12-09 12:50:34 MYSENSORS MySensors.Gateway inclusion-mode on

Im Log auf ttyUSB0 tut sich nichts. Im FHEM-Log auch nicht.

Dann schalte ich den Sensor ein. Auf ttyUSB0:
Zitat
0;255;3;0;9;TSF:MSG:READ,255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;TSF:MSG:BC
0;255;3;0;9;TSF:MSG:FPAR REQ,ID=255
0;255;3;0;9;TSF:PNG:SEND,TO=0
0;255;3;0;9;TSF:CKU:OK
0;255;3;0;9;TSF:MSG:GWL OK
0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
0;255;3;0;9;TSF:MSG:READ,255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;TSF:MSG:BC
0;255;3;0;9;TSF:MSG:FPAR REQ,ID=255
0;255;3;0;9;TSF:CKU:OK,FCTRL
0;255;3;0;9;TSF:MSG:GWL OK
0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
0;255;3;0;9;TSF:MSG:READ,255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;TSF:MSG:BC
0;255;3;0;9;TSF:MSG:FPAR REQ,ID=255
0;255;3;0;9;TSF:CKU:OK,FCTRL
0;255;3;0;9;TSF:MSG:GWL OK
0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
0;255;3;0;9;TSF:MSG:READ,255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;TSF:MSG:BC
0;255;3;0;9;TSF:MSG:FPAR REQ,ID=255
0;255;3;0;9;TSF:CKU:OK,FCTRL
0;255;3;0;9;TSF:MSG:GWL OK
0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0

uswusf....

Link zum Parser:
https://www.mysensors.org/build/parser?log=0%3B255%3B3%3B0%3B9%3BTSF%3AMSG%3AREAD%2C255-255-255%2Cs%3D255%2Cc%3D3%2Ct%3D7%2Cpt%3D0%2Cl%3D0%2Csg%3D0%3A%0A0%3B255%3B3%3B0%3B9%3BTSF%3AMSG%3ABC%0A0%3B255%3B3%3B0%3B9%3BTSF%3AMSG%3AFPAR%20REQ%2CID%3D255%0A0%3B255%3B3%3B0%3B9%3BTSF%3APNG%3ASEND%2CTO%3D0%0A0%3B255%3B3%3B0%3B9%3BTSF%3ACKU%3AOK%0A0%3B255%3B3%3B0%3B9%3BTSF%3AMSG%3AGWL%20OK%0A0%3B255%3B3%3B0%3B9%3BTSF%3AMSG%3ASEND%2C0-0-255-255%2Cs%3D255%2Cc%3D3%2Ct%3D8%2Cpt%3D1%2Cl%3D1%2Csg%3D0%2Cft%3D0%2Cst%3DOK%3A0%0A0%3B255%3B3%3B0%3B9%3BTSF%3AMSG%3AREAD%2C255-255-255%2Cs%3D255%2Cc%3D3%2Ct%3D7%2Cpt%3D0%2Cl%3D0%2Csg%3D0%3A%0A0%3B255%3B3%3B0%3B9%3BTSF%3AMSG%3ABC%0A0%3B255%3B3%3B0%3B9%3BTSF%3AMSG%3AFPAR%20REQ%2CID%3D255%0A0%3B255%3B3%3B0%3B9%3BTSF%3ACKU%3AOK%2CFCTRL%0A0%3B255%3B3%3B0%3B9%3BTSF%3AMSG%3AGWL%20OK%0A0%3B255%3B3%3B0%3B9%3BTSF%3AMSG%3ASEND%2C0-0-255-255%2Cs%3D255%2Cc%3D3%2Ct%3D8%2Cpt%3D1%2Cl%3D1%2Csg%3D0%2Cft%3D0%2Cst%3DOK%3A0%0A0%3B255%3B3%3B0%3B9%3BTSF%3AMSG%3AREAD%2C255-255-255%2Cs%3D255%2Cc%3D3%2Ct%3D7%2Cpt%3D0%2Cl%3D0%2Csg%3D0%3A%0A0%3B255%3B3%3B0%3B9%3BTSF%3AMSG%3ABC%0A0%3B255%3B3%3B0%3B9%3BTSF%3AMSG%3AFPAR%20REQ%2CID%3D255%0A0%3B255%3B3%3B0%3B9%3BTSF%3ACKU%3AOK%2CFCTRL%0A0%3B255%3B3%3B0%3B9%3BTSF%3AMSG%3AGWL%20OK%0A0%3B255%3B3%3B0%3B9%3BTSF%3AMSG%3ASEND%2C0-0-255-255%2Cs%3D255%2Cc%3D3%2Ct%3D8%2Cpt%3D1%2Cl%3D1%2Csg%3D0%2Cft%3D0%2Cst%3DOK%3A0%0A0%3B255%3B3%3B0%3B9%3BTSF%3AMSG%3AREAD%2C255-255-255%2Cs%3D255%2Cc%3D3%2Ct%3D7%2Cpt%3D0%2Cl%3D0%2Csg%3D0%3A%0A0%3B255%3B3%3B0%3B9%3BTSF%3AMSG%3ABC%0A0%3B255%3B3%3B0%3B9%3BTSF%3AMSG%3AFPAR%20REQ%2CID%3D255%0A0%3B255%3B3%3B0%3B9%3BTSF%3ACKU%3AOK%2CFCTRL%0A0%3B255%3B3%3B0%3B9%3BTSF%3AMSG%3AGWL%20OK%0A0%3B255%3B3%3B0%3B9%3BTSF%3AMSG%3ASEND%2C0-0-255-255%2Cs%3D255%2Cc%3D3%2Ct%3D8%2Cpt%3D1%2Cl%3D1%2Csg%3D0%2Cft%3D0%2Cst%3DOK%3A0

Im Event Monitor und im FHEM-Log tut sich nichts...

Leider weiss ich jetzt nicht, wie ich das interpretieren soll.


TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0

Sent Message
Sender: 0
Last Node: 0
Next Node: 255
Destination: 255
Sensor Id: 255
Command: INTERNAL
Message Type:I_FIND_PARENT_RESPONSE
Payload Type: P_BYTE
Payload Length: 1
Signing: 0
Failed uplink counter: 0
Status: OK (OK=success, NACK=no radio ACK received)
Payload: 0


Klingt für mich nach: Gateway schickt dem Sensor erfolgreich eine Antwort. Aber gleich danach...


TSF:MSG:READ,255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0:

Received Message
Sender: 255
Last Node: 255
Destination: 255
Sensor Id: 255
Command: INTERNAL
Message Type: I_FIND_PARENT_REQUEST
Payload Type: P_STRING
Payload Length: 0
Signing: 0
Payload:


... empfängt das Gateway schon wieder ein I_FIND_PARENT_REQUEST. Ist der Node taub?

Ich gelobe feierlich einen Kasten Bier (oder äquivalentes Getränkt) für den Hinweis der mich weiterbringt. Ich würde so gerne endlich richtig loslegen :(

Schönes Wochenende (und hoffentlich bis bald)
Markus

The Grue

Oh, und weil danach immer wieder mal gefragt wird:

Das Oszi zeigt an der Stromversorgung des Funkmoduls 3.28V aber sowas von glatt an. Kein Ripple, nix. Es sind auch 22µ über Vcc und Gnd.

Selbiges an der Stromversorgung des Gateway-Funkmoduls. Das ist eines mit pa und Antenne, das per LM317 seine 3.3V bekommt. Was mich hier wundert: Das Multimeter zeigt eine Stromaufname von 20mA nach der Initialisierung - da hätte ich mehr erwartet  :-\

Ranseyer

...es gibt ja auch Fake-Module inkl. zueinander inkompatiblen...
(Ich habe kürzlich meine lange gelagerten NRFs verkauft, damals gab es noch kaum Fakes. Wenn der Chip fein abgeschliffen aussieht, also oben rauher ist als seitlich würde ich mal in Richtung Fake denken)


Denke sinnvoll testen kann man nur wenn man bei nem HW Fehler sowohl den Sensor und auch notfalls das Gateway doppelt hat.
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Beta-User

Jup, mehr Hardware zum gegenseitigen Testen hilft.

Das mit dem "ist der Sensor taub" kling für mich plausibel. Spekulation: MOSI-Leitung mit Wackler? (sowas hatte - wenn ich das richtig verstanden habe - neulich jemand mit einem CC1101, ich konnte es kaum glauben, weil der Chip scheinbar spielte...)

Wenn es an der Antwort auf die ID-Anfrage scheitert, kannst du die testweise ja mal manuell vergeben, dann siehst du wenigstens, ob der Sensor dann ordentlich angelegt wird (dürfte eigentlich dann keine oder weniger Antworten vom GW erwarten).

Ich würde auch erst mal nicht mit einem Ethernet-GW anfangen, aber auch daran scheint es ja nicht zu liegen. Trotzdem: Welche Version nutzt du aktuell? - Neulich gab es einen Bericht über ein Eth-GW unter 2.1.1, bei dem sich die Probleme in Luft auflösten, als 2.2.0-beta einfach funktionierte.

Um erste funktionierende HW zu haben, wäre ein serielles GW  -ggf. an einem Test-System - eine Idee. Erst mal das ans laufen bekommen, dann hat man ein erstes Gefühl, wie es "eigentlich" gehen sollte. Das GW kann nachher ja auch zum Repeater umgewidmet werden, dann kann man die Kommunikation mithören.

Wo gäbe es ggf. den Kasten?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

The Grue

Zitat von: Beta-User am 09 Dezember 2017, 14:37:37
Das mit dem "ist der Sensor taub" kling für mich plausibel. Spekulation: MOSI-Leitung mit Wackler? (sowas hatte - wenn ich das richtig verstanden habe - neulich jemand mit einem CC1101, ich konnte es kaum glauben, weil der Chip scheinbar spielte...)

Werde ich gleich mal testen.

Zitat
Wenn es an der Antwort auf die ID-Anfrage scheitert, kannst du die testweise ja mal manuell vergeben, dann siehst du wenigstens, ob der Sensor dann ordentlich angelegt wird (dürfte eigentlich dann keine oder weniger Antworten vom GW erwarten).

Würde ich auch versuchen... weiss leider nicht wie  :-[ Hinweise auf die Doku sind sehr willkommen :)

Zitat
Welche Version nutzt du aktuell? - Neulich gab es einen Bericht über ein Eth-GW unter 2.1.1, bei dem sich die Probleme in Luft auflösten, als 2.2.0-beta einfach funktionierte.

VER=2.1.1 ... Mal sehen, wo ich 2.2.0-beta finde. Danke für den Hinweis!

Zitat
Um erste funktionierende HW zu haben, wäre ein serielles GW  -ggf. an einem Test-System - eine Idee.

Daran soll's nicht scheitern. Was sind denn die Vorteile am seriellen Gateway? Ich hab' halt noch so wenig Ahnung von der Stuktur...

Zitat
Wo gäbe es ggf. den Kasten?

Äh, wie bitte? Keine Ahnung, was du meinst...


Jetzt werde ich erst mal Punkt für Punkt Eure Hinweise durchgehen - vielen Dank dafür! Außerdem habe ich ein "RF24-GettingStarted" gefunden, mit dem ich vielleicht testen kann, ob und in welche Richtungen die beiden Chips miteinander reden.

Wenn's zeitlich rausgeht, melde ich mich heute Abend wieder, bis dahin schon mal einen schönen Sonntag!

cu
/me

Sweeman

Hallo The Grue,

ich kann ein kleines Lied von diesen Problemen singen. Leider habe ich keine richtige Lösung parat, aber ein paar Hinweise, die vielleicht zu einer stabilen Connection führen.

1. nRF24 Module sind (soweit ich sie in Händen hatte) eher Schrott  :-X Als ich mal den Widerstand zwischen Ant und Grnd gemessen habe, kam ich da auf gerade mal 3 Ohm und ich bin zwar kein Kommunikationstechniker, aber eigentlich sollte der dort recht Hoch sein (die Erfahrung habe ich auch mit allen anderen Modulen, wie dem RFM69 gemacht. Dort ist keine Verbindung).
Die Antennenposition war hier schon teilweise ausschlaggebend, da anscheinend ein Wackler ab Werk verbaut war. Also mal beherzt rumwackeln, Antenne ab und gucken, ob es dann über eine kurze Distanz funktioniert, wieder dran etc....
2. Solltest du das ganze auf einem Breadboard laufen haben, versuche mal alle Verbindungen zu überprüfen oder die Jumper zu wechseln. Ein Jumperkabel mit Wackler kann einem ziemlich das Projekt verhageln.
3. Ich hatte schon Hardware, die nicht am gleichen PC auf einem Breadboard funktionieren wollte. Wirklich! Kaum habe ich das PCB vom Board gezogen funktioniert alles wunderbar. Die Lösung war hier für eine Komponente (GW oder Sender) eine andere Spannungsquelle zu verwenden. Also Batterien oder USB-Netzteil. Es ist also tatsächlich Hexerei im Spiel ;)
4. Wie sieht denn dein Code aus? Mit so manchem hat FHEM seine Probleme. Strings z.B. sind so eine Sache... Das funktioniert nicht immer so einfach, wie man es sich vorstellt.
5. Du rufst aber nicht immer auch den seriellen Monitor ab, während du versuchst mit FHEM zu empfangen? Meine Erfahrung ist, dass nur eine Connection möglich ist.
6. Die ältere MySensors-Version kannst du unter "Bibliotheken verwalten" in der Arduino IDE installieren. Einfach MySensors suchen und dort auf die Version unten links klicken und installieren.
7. Welche ID hat dein Sensor? 0 ist vom Gateway besetzt. Du musst also irgendwas zwischen 1 und 255 wählen.

Ich hoffe ich konnte irgendwie helfen.
Viele Grüße


The Grue

Also auf Clock, MISO und MOSI tut sich schon mal was, das richtig aussieht. Ist MOSI active low?

The Grue

Mit 2.2.0-rc2 wurde immerhin schon mal MYSENSOR_0 vom Gateway automatisch angelegt. Ansonsten leider keine Fortschritte.
Ich habe auch mal versucht, das PingPong-Device zum Testen zu verwenden. Auf dem Sensor-Node hat das auch funktioniert, auf dem Gateway gibt's einen Fehler beim Initialisieren :(

Zu Deinen Fragen, Sweeman: 1-3: Klingt ja furchtbar. Ich hatte mich über MySensors gefreut, weil das ganze Framework so gut aussah, daß ich mit meinen Sensoren schnell loslegen kann. Geht ja gerade gründlich in die Hose.

4: Der Gateway-Code kommt direkt aus der MySensor-Bibliothek. Der Sensorcode  ist 1:1 der aus den Examples zum DHT-Sensor.
5: Doch. Wie kann ich sonst überhaupt debuggen? Die nächsten Male versuche ich nur jeweils einen Node zu debuggen.
6: Naja, eigentlich wollte ich ja die neueren Versionen ;) Hat aber geklappt.
7: Ich hatte die Defaults gelassen (also AUTO für beides). Aber jetzt hab' ich auch mal explizit 0 für's Gateway und 1 für den Sensor gesetzt - hat auch nichts geholfen.

Beta-User

Zitat von: The Grue am 10 Dezember 2017, 14:25:58
Äh, wie bitte? Keine Ahnung, was du meinst...
Dieser Kasten war gemeint:
Zitat von: The Grue am 09 Dezember 2017, 13:14:37
Ich gelobe feierlich einen Kasten Bier (oder äquivalentes Getränkt) für den Hinweis der mich weiterbringt. Ich würde so gerne endlich richtig loslegen :(

Das mit dem seriellen GW hat sich erledigt, wenn du die Node_0 angelegt bekommst; dann funktioniert jedenfalls dieser Arduino; ein serielles GW hat den Vorteil, dass alles als Fehlerquelle ausscheidet, was mit Netzwerk zu tun hat (eingeschlossen diverse Bugs, die aus dem Eth-Modul kommen können - Widerstände waren da manchmal ein Thema - selber suchen, ich nehme bewußt serielle GW's...).

Und die Ausgaben an den seriellen Konsolen sind esentiell - sonst hat man keine Chance, irgendwas zu debuggen (darum auch der Vorschlag, eine Repeater-Node zu nutzen, dann sieht man, was hin- und hergeht, oder eben nicht...). Ggf. muß man halt 2 Rechner nutzen, um zu sehen, was an beiden Enden läuft (das kann aber die Kommunikation mit FHEM stören, deswegen mache ich sowas am GW nie, wenn ich weiß, dass das GW funktioniert).

Das ganze klingt immer noch nach Funkproblemen auf Sensor-Seite, auch wenn ich zu den Soll-Pegeln an MOSI nix sagen kann. Du solltest neben dem GW und dem einen Sensor eine weitere HW nehmen, um testen zu können, wo genau der Fehler liegt - im Funkbereich oder in der (fehlenden) Antowort vom GW bzw. von FHEM.

Und 255 ist _keine_ zulässige Node-ID. Das ist die Broadcast-Adresse...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

The Grue

Servus Beta-User,

Bitte entschuldige, daß ich mich erst jetzt wieder melde. War einfach zu viel Anderes los. Als nächstes möchte ich dann einen anderen Node bauen (Dallas one-wire Temperatursensor). Mal sehen, ob der in's Netz findet.

Das mit dem "Kasten" klingt ja ganz übel - von meiner Seite. Aber: ich habe ich nicht kapiert, was Du meinst und der Kasten ist auch noch ernst gemeint. Wenn ich meine erste laufende Kommunikation hinbekommen habe, lese ich mir diesen Thread nochmal genau durch und entscheide wer ihn bekommt. Ich wohne im Münchner Osten (Landkreis Ebersberg), aber ich hoffe doch, daß man heutzutage so ein Ding auch irgendwie zustellen lassen kann... jedenfalls im EU-Binnenmarkt ;)

cu
Markus