Relais Steuerung

[Markus.]

Hallo Zusammen,

bin mir gerade mal einen Relais-Node am aufbauen. Also Hardware ist ein Arduino pro mini 3,3V auf einem Easy PCB. Versuchen will ich das ganze mal über Batteriebetrieb wobei ich schlussendlich auf eine 3,3 Volt Stromquelle zurückgreifen werde.
Im Sketch hab ich mal ein Relais definiert. Für den Anfang will ich nur mal mit dem Digitalen Ausgang rumspielen an dem ich eine LED angeschlossen habe. Aber irgendwie verbindet er sich nicht mit dem Gateway. Wäre klasse wenn sich mal einer den Sketch anschauen könnte ob es eventuell daran liegt. Wenn nicht muss ich nochmal Spannungsversorgung und Kondensator vom NRF nachschauen.

Code Auswählen Erweitern


// Enable debug prints to serial monitor
#define MY_DEBUG

// Enable and select radio type attached
#define MY_RADIO_NRF24


//#define MY_RADIO_NRF5_ESB
//#define MY_RADIO_RFM69
//#define MY_RADIO_RFM95

// Enable repeater functionality for this node
//#define MY_REPEATER_FEATURE

#include <MySensors.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


void before()
{
    for (int sensor=1, pin=RELAY_1; sensor<=NUMBER_OF_RELAYS; sensor++, pin++) {
        // Make sure relays are off when starting up
        digitalWrite(pin, RELAY_OFF);
        // Then set relay pins in output mode
        pinMode(pin, OUTPUT);
        // Set relay to last known state (using eeprom storage)
        digitalWrite(pin, loadState(sensor)?RELAY_ON:RELAY_OFF);
    }
}

void setup()
{

}

void presentation()
{
    // Send the sketch version information to the gateway and Controller
    sendSketchInfo("Relay", "1.0");

    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)
        present(sensor, S_BINARY);
    }
}


void loop()
{

}

void receive(const MyMessage &message)
{
    // We only expect one type of message from controller. But we better check anyway.
    if (message.type==V_STATUS) {
        // Change relay state
        digitalWrite(message.sensor-1+RELAY_1, message.getBool()?RELAY_ON:RELAY_OFF);
        // Store state in eeprom
        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());
    }
}

Ist eigentlich der Standard Sketch von Mysensors...

Gruß

Markus

[Markus.]

hier noch die Meldung der Konsole...

Code Auswählen Erweitern


0 MCO:BGN:INIT NODE,CP=RNNNA--,VER=2.1.1
4 MCO:BGN:BFR
4 TSM:INIT
6 TSF:WUR:MS=0
12 TSM:INIT:TSP OK
14 TSM:FPAR
16 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2025 !TSM:FPAR:NO REPLY
2027 TSM:FPAR
2029 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
4038 !TSM:FPAR:NO REPLY
4040 TSM:FPAR
4042 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
6051 !TSM:FPAR:NO REPLY
6053 TSM:FPAR
6055 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
8065 !TSM:FPAR:FAIL
8067 TSM:FAIL:CNT=1
8069 TSM:FAIL:PDT



ich hab jetzt mal einen funktionierten Node umgeflasht und da ist das selbe...

[Beta-User]

...das hat auch nichts mit Relais zu tun; ich nehme mal an, das ist Deine erste Node überhaupt, oder?

Der Inclusion Mode am GW ist an? autocreate auch?
Wie weit ist die Node vom GW weg?
Was siehst Du an der Konsole, wenn Du das GW betrachtest; kommt da was an?

Gruß, Beta-User

[Markus.]

nee habe ca. 8 DHT22 am laufen. Der Node ist ca. 2 Meter vom Gateway weg. autocreate is an der Inclusion mode ist auch auf 1.
Am Gateway kommen nur Infos von den anderen Nodes...

Gruß

Markus

[Markus.]

aber mal ne blöde frage zwischendurch....

wie kann ich putty denn so einstellen, das die Statuszeilen unter einander kommen und nicht immer so versetzt??

Code Auswählen Erweitern


0;255;3;0;14;Gateway startup complete.
                                      0;255;0;0;18;2.1.1
                                                        100;0;1;0;0;24.8
                                                                        100;255;                                                                             3;0;0;87
        100;5;1;0;38;3.58
                         103;1;1;0;0;22.7
                                         103;255;3;0;0;79
                                                         103;3;1;0;38;3.26
                                                                          102;0;                                                                             1;0;1;49.7
          102;255;3;0;0;89
                          102;3;1;0;38;3.66
                                           107;1;1;0;0;24.1
                                                           107;0;1;0;1;45.8
                                                                           107;2                                                                             55;3;0;0;92
           107;3;1;0;38;3.78
                            106;1;1;0;0;24.4
                                            106;0;1;0;1;48.6
                                                            106;255;3;0;0;87
                                                                            106;                                                                             3;1;0;38;3.58
             104;1;1;0;0;23.6
                             104;0;1;0;1;44.8
                                             104;255;3;0;0;86
                                                             104;3;1;0;38;3.57
                                                                              105;0;1;0;1;66.8
                                                                                              105;255;3;0;0;84
                                                                                                              105;3;1;0;38;3.47
                                                                                                                               102;1;1;0;0;23.5
                                                                                                                                               102;0;1;0;1;50.2
  102;255;3;0;0;88
                  102;3;1;0;38;3.65
                                   100;0;1;0;0;24.8
                                                   100;255;3;0;0;87
                                                                   100;5;1;0;38;3.58
                                                                                    103;255;3;0;0;79
                                                                                                    103;3;1;0;38;3.26
                                                                                                                     102;255;3;0;0;89
                                                                                                                                     102;3;1;0;38;3.67
                                                                                                                                                      108;1;1;0;0;27.6
         108;2;1;0;1;52
                       107;1;1;0;0;24.2
                                       107;0;1;0;1;45.7
                                                       107;255;3;0;0;91
                                                                       107;3;1;0;38;3.77
                                                                                        106;1;1;0;0;24.5
                                                                                                        106;0;1;0;1;48.4
                                                                                                                        106;255;3;0;0;87
                                                                                                                                        106;3;1;0;38;3.58
                                                                                                                                                         104;255;3;0;0;87
            104;3;1;0;38;3.58
                             105;0;1;0;1;58.9
                                             105;255;3;0;0;84
                                                             105;3;1;0;38;3.47
                                                                              100;0;1;0;0;24.8
                                                                                              100;255;3;0;0;87
                                                                                                              100;5;1;0;38;3.58



[Beta-User]

Zu putty kann ich nichts sagen...

Hast Du was am Kanal verändert?
Welchen SW-Stand hat das GW (sollte immer >=der Node-Versionen sein)?

Welche Versionen haben die anderen Nodes?

[Markus.]

Am kanal hab ich auch nichts geändert. Version am gateway und alle nodes ist 2.1.1. irgendwie sehr seltsam. Gibt es irgendwie einen minimal sketch den ich mal testen kann? Hab iregdnwie das gefühl das es doch am sketch liegt. Will jetzt auch nicht einen funktionierenden sensor auseinander bauen...

Gruß

Markus

[Beta-User]

Die Ausgabe der Seriellen Konsole der Node ist eindeutig: Keine Kommunikation.

Wenn es ein SW-Problem ist, dann im Funk-Bereich, aber m.E. nicht beim Rest. Versuche mal, die nRF-lib entweder upzudaten oder wieder down (im library-MAnager der IDE, wenn Du die benutzt). Ist bei mir aktuell 1.3, aber Achtung: ich habe schon eine Weile keine nRF-Nodes mehr neu aufgesetzt, nur gesehen, dass die lib aktualisiert wurde.

[Markus.]

Die NRF Lib ist Version 1.3. hab mal nach einem downgrade geflasht mit gleichem Ergebnis. Aber diese Lib wird doch auch garnicht verwendet im Sketch ??!! Es wird doch nur die MySensors verwendet..
Ich bau morgen mal einen Dallas Sensor dran und versuch das Ding mal als Temperatur Sensor zum laufen zu bekommen..
Irgendwie sehr seltsam das alles

[Beta-User]

Du hast recht, MySensors scheint eine eigene RF24-lib zu nutzen.

Habe eben einen schnellen Test mit einer Repeater-Node gemacht. Jedenfalls bei Version 2.2.0-beta ist der Kommunikationslayer an sich i.O..

[Markus.]

ich check morgen nochmal die Hardware, besonders die Spannungsversorgung. Werde dann mal weiter berichten. Bin mal gespannt wo der Fehler dann schlussendlich liegt..

erstmal danke für deine Hilfe hier !!

Gruß

Markus

[Markus.]

so habe gestern mal weiter geforscht und habe mal Spannungsversorgung überprüft, Verkabelung usw. Sieht soweit alles gut aus.
Dann habe ich mal aus dem Sensor einen Dallas Temperatur Sensor gebaut und geflasht, was ja bisher immer funktioniert hat. Sie da selbes Problem. Erst als ich dann das FHEM samt OS und Gateway mehrmals neu gestartet hatte wurde der Sensor erkannt. Der Sensor übertrug auch zeitweise Daten. Dann habe ich das Relais-Sketch geladen und auch dieser wurde soweit erkannt und angelegt in FHEM. Jedoch wars das auch schon kein schalten möglich ..

So langsam habe ich das Gefühl das das Problem an den ALI-China-NRF24L01 Modulen liegt. Hatte da mal ein Packet mit 10 Modulen geholt... Nunja hab mir jetzt mal neue bestellt von einen Shop hier in Deutschland von dem auch die anderen sind die funktioniert haben.
Bin mal gespannt...

Achso als Nachtrag noch am NRF habe ich zur Zeit nur einen 4,7yf Kondensator will da mal einen grösseren testen bis die neuen NRFs kommen.

[smoudo]

Ich habe das selbe Phänomen mit den nrf Chips. Auf nem 10er pcb vom Ali hab ich 2 drauf die Funken top.
Beim Rest keine 5 Meter mit Sicht. Habe das Problem aber auch mit Modulen aus deutschen Shops. Ich vermute riesige serienstreuungen. Werde bei Zeit mal mit wired experimentieren, ansonsten auf rfm wechseln.

Grüße

Matze

[Markus.]

mmh Umrüsten auf rfm wäre auch ne Möglichkeit.Aber bin eigentlich soweit zufrieden mit der Leistung/Reichweite bei den NRFs seitdem ich das Gateway auf nrf24l01 + PA + lna umgebaut habe. Aber mal schauen was die neuen Module dann machen. Eventuell hab ich ja doch wo anders das eigentliche Problem ...

[Markus.]

Hat zufällig einer einen Relais-Sketch mit Button bei dem das Relais auch ohne ack vom Controller geschaltet wird?

Also völlig autark vom Controller? Wird eigentlich das notwendige ack von FHEM übehaupt gesendet wenn ich den Relais/Button Sketch von Mysensors verwende?
Beim betätigen des Buttons mit diesem Sketch wird ja eigentlich der Statusänderungs-Request ans Gateway geschickt. Dann muss ja zum ausführen des eigentlichen Schaltbefehls das ack vom Controller zurück kommen oder?

Code Auswählen Erweitern


void receive(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
     state = message.getBool();
     digitalWrite(RELAY_PIN, state?RELAY_ON:RELAY_OFF);
     // Store state in eeprom
     saveState(CHILD_ID, state);

     // Write some debug info
     Serial.print("Incoming change for sensor:");
     Serial.print(message.sensor);
     Serial.print(", New status: ");
     Serial.println(message.getBool());
   }
}




Gruß

Markus

[Beta-User]

Hallo Markus.,

das mit dem Ack hat zwei Seiten: der Relay mit Button-Sketch bei "build" sendet mit Ack-Anforderung. Das kannst Du aber ändern:

Code Auswählen Erweitern

if (value != oldValue && value==0) {
      send(msg.set(state?false:true), false); // Send new state and request ack back
  }
Ob FHEM ein Ack anfordert, wäre bei der Node in FHEM einzustellen.

Wenn Du willst, dass die Node auch ohne Verbindung zum GW startet, wäre das mit

Code Auswählen Erweitern

#define MY_TRANSPORT_WAIT_READY_MS 3000zu lösen.

[Markus.]

kannst du mir mal auf die Sprünge helfen wie das aussehen muss ?

Code Auswählen Erweitern



if (value != oldValue && value==0) {
      send(msg.set(state), false);  // ack back dann egal

}


Das andere hab ich mal im Sketch drin..

Gruß

Markus

[Beta-User]

Das andere hab ich mal im Sketch drin..

Deute ich das richtig: Du hast das in der loop() geändert wie im Code-Vorschlag (der Kommentar war noch alt, der Rest hat gepaßt) und dann noch das MY_TRANS... definiert (im header)?

Innerhalb von FHEM ist die Ack-Anforderung ein Attribut bei der jeweiligen Node (requestAck), das kann 0 oder 1 sein (0=kein Ack anfordern, wenn ich das richtig deute).

[Markus.]

Ja der Loop sieht nun wie folgt aus

Code Auswählen Erweitern


void loop()
{
  debouncer.update();
  // Get the update value
  int value = debouncer.read();
if (value != oldValue && value==0) {
      send(msg.set(state), false);  // ack back dann egal
   
  }
  oldValue = value;
}




Und der Header nun so

Code Auswählen Erweitern


#define MY_RADIO_NRF24

#include <MySensors.h>
#include <SPI.h>
#include <Bounce2.h>

#define RELAY_PIN 5  // Arduino Digital I/O pin number for relay
#define BUTTON_PIN 6  // Arduino Digital I/O pin number for button
#define CHILD_ID 1   // Id of the sensor child
#define RELAY_ON 1
#define RELAY_OFF 0
#define MY_TRANSPORT_WAIT_READY_MS 3000


Mit dem Attribut muss ich nachher mal schauen...

Gruß

Markus

[Markus.]

mal ne blöde frage zum Sketch selber....
Kann ich dann den Status des Relais über beide Wege ändern? also einmal über den Button und zum anderen auch über FHEM?
Oder kann man mit dem Sketch nur über den Button das Relais schalten?

Gruß

Markus

[Beta-User]

Die Antwort steht in loop() und receive()...

Beide Wege sind angelegt .

[Markus.]

so habe mal weiter getestet und einen funktionierenden Sensor verwendet.
Habe das eeprom gelöscht mit dem Mysensors Sketch und das device aus FHEM gelöscht.
Sensor gestartet in der Annahme, das er direkt wieder erkannt wird. Aber nichts... das selbe Problem wie mit den neuen Sensoren und neuen NRFs. Dann habe ich nochmal einen kompletten Sensor aufgebaut mit dieser NRF interfaceplatine und Kabeln aber auch da das selbe Problem. Alles in allem sieht es doch nun aus als wenn das Gateway spinnt..
Hatte sowas schon mal jemand??
Hab noch ein anderes Gateway hier liegen denke das werde ich mal flashen und testen. Die existierenden Sensoren haben ja schon ihre IDs und dürften sie behalten oder? Dann sollte doch auch alles auf FHEM-Seite funktionieren....!?

Gruß

Markus 

[Beta-User]

Was Du da machst, kommt mir reichlich konfus vor ...

Wenn Du eine funktionierende Installation hast (mehrere Sensoren+GW), dann kann es eigentlich nur irgendwas sein, das Du neu machst. Ich verdächtige weiterhin die Kanalwahl, ggf. auch die Sendeleistung (mal reduzieren), oder eine Inkompabilität der verwendeten SW zu einem alten SW-Stand (eher unwahrscheinlich).

Was ist das für ein GW? Du kannst das GW tauschen, der Rest bleibt ja erhalten. Einfacher ist es, sich in den Verkehr mit einer Repeater-Node reinzuhängen.

Die NodeID wird im EEPROM gespeichert, sonst eigentlich nichts wichtiges. Beim normalen Neuflashen bleibt das erhalten; will man das nicht, reicht es, diese im Sketch neu zu vergeben, man muß nix löschen... Aber ein neues GW hat darauf keinen Einfluß, FHEM kennt nur die NodeID zur internen Verwaltung.

[Markus.]

Bezüglich des funkkanals habe ich eigentlich nie was geändert. Bei den sketches wird doch da immer der default Kanal aus der config von Mysensors geholt. Mit der Sendeleistung hab ich auch schon durchprobiert mit low und min.
Aber wie stelle ich das denn an mit dem Repeater um damit den Funkverkehr sehen zu können?
Das Gateway ist eins vom Hexenmeister mit einem Nrf24l01 lna pa
Gruß

Markus

[Beta-User]

Repeater=Arduino+nRF+Repeater-Node-Sketch (oder jede andere Node, die als Repeater konfiguriert ist (MY_REPEATER_FEATURE oder so). Das GW sollte eigentlich ok sein, auch wenn ich wohl in diesem Leben nicht mehr verstehen werde, warum man unbedingt irgendeine Netzwerkkomponente dazwischenschalten muß und nicht einfach einen Arduino an den USB-Port des Servers hängt (wenn man nicht grade einen virtualisierten Server betreibt), aber was solls .

Den Funkverkehr solltest Du dann an der seriellen Konsole der Arduino-IDE verfolgen können, insbesondere  dann z.B. erfolglose Verbindungsversuche Deiner neuen Nodes sehen. Auch sollte zu erkennen sein, ob sich wenigstens der Repeater  in Dein bestehendes Netz einklinkt (vermutlich nicht).

Sehen sich die neuen Geräte gegenseitig, weist Du wenigstens, dass die HW jeweils in Ordnung ist und irgendwas anderes faul.

[Markus.]

Hallo,

Wollte mal einen Zwischenstatus abgeben...

Also die Repeater-Node hat sich natürlich nicht mit dem bestehenden Sensornetz verbunden wie Du ja schon gesagt hast Um mal wirklich die Hardware auschliessen zu können habe ich auf den zwei neuen Nodes dieses send/receive geflasht

Code Auswählen Erweitern



/*
* Getting Started example sketch for nRF24L01+ radios
* This is a very basic example of how to send data from one node to another
* Updated: Dec 2014 by TMRh20
*/

#include <SPI.h>
#include "RF24.h"

/****************** User Config ***************************/
/***      Set this radio as radio number 0 or 1         ***/
bool radioNumber = 1;

/* Hardware configuration: Set up nRF24L01 radio on SPI bus plus pins 7 & 8 */
RF24 radio(9,10);
/**********************************************************/

byte addresses[][6] = {"1Node","2Node"};

// Used to control whether this node is sending or receiving
bool role = 0;

void setup() {
  Serial.begin(115200);
  Serial.println(F("RF24/examples/GettingStarted"));
  Serial.println(F("*** PRESS 'T' to begin transmitting to the other node"));
 
  radio.begin();

  // Set the PA Level low to prevent power supply related issues since this is a
// getting_started sketch, and the likelihood of close proximity of the devices. RF24_PA_MAX is default.
  radio.setPALevel(RF24_PA_MIN);
 
  // Open a writing and reading pipe on each radio, with opposite addresses
  if(radioNumber){
    radio.openWritingPipe(addresses[1]);
    radio.openReadingPipe(1,addresses[0]);
  }else{
    radio.openWritingPipe(addresses[0]);
    radio.openReadingPipe(1,addresses[1]);
  }
 
  // Start the radio listening for data
  radio.startListening();
}

void loop() {
 
 
/****************** Ping Out Role ***************************/ 
if (role == 1)  {
   
    radio.stopListening();                                    // First, stop listening so we can talk.
   
   
    Serial.println(F("Now sending"));

    unsigned long start_time = micros();                             // Take the time, and send it.  This will block until complete
     if (!radio.write( &start_time, sizeof(unsigned long) )){
       Serial.println(F("failed"));
     }
       
    radio.startListening();                                    // Now, continue listening
   
    unsigned long started_waiting_at = micros();               // Set up a timeout period, get the current microseconds
    boolean timeout = false;                                   // Set up a variable to indicate if a response was received or not
   
    while ( ! radio.available() ){                             // While nothing is received
      if (micros() - started_waiting_at > 200000 ){            // If waited longer than 200ms, indicate timeout and exit while loop
          timeout = true;
          break;
      }     
    }
       
    if ( timeout ){                                             // Describe the results
        Serial.println(F("Failed, response timed out."));
    }else{
        unsigned long got_time;                                 // Grab the response, compare, and send to debugging spew
        radio.read( &got_time, sizeof(unsigned long) );
        unsigned long end_time = micros();
       
        // Spew it
        Serial.print(F("Sent "));
        Serial.print(start_time);
        Serial.print(F(", Got response "));
        Serial.print(got_time);
        Serial.print(F(", Round-trip delay "));
        Serial.print(end_time-start_time);
        Serial.println(F(" microseconds"));
    }

    // Try again 1s later
    delay(1000);
  }



/****************** Pong Back Role ***************************/

  if ( role == 0 )
  {
    unsigned long got_time;
   
    if( radio.available()){
                                                                    // Variable for the received timestamp
      while (radio.available()) {                                   // While there is data ready
        radio.read( &got_time, sizeof(unsigned long) );             // Get the payload
      }
     
     delay(500);
      radio.stopListening();                                        // First, stop listening so we can talk   
      radio.write( &got_time, sizeof(unsigned long) );              // Send the final one back.     
      radio.startListening();                                       // Now, resume listening so we catch the next packets.     
      Serial.print(F("Sent response "));
      Serial.println(got_time); 
   }
}




/****************** Change Roles via Serial Commands ***************************/

  if ( Serial.available() )
  {
    char c = toupper(Serial.read());
    if ( c == 'T' && role == 0 ){     
      Serial.println(F("*** CHANGING TO TRANSMIT ROLE -- PRESS 'R' TO SWITCH BACK"));
      role = 1;                  // Become the primary transmitter (ping out)
   
   }else
    if ( c == 'R' && role == 1 ){
      Serial.println(F("*** CHANGING TO RECEIVE ROLE -- PRESS 'T' TO SWITCH BACK"));     
       role = 0;                // Become the primary receiver (pong back)
       radio.startListening();
       
    }
  }


} // Loop


Beide Nodes funktioneren einwandfrei und reden miteinander. So Hardware ist also soweit in Ordnung...Juhuu
Dann wieder auf dem Relais-Node das entsprechende Sketch geladen.. Nix passiert selber Fehler. Dann mal meinen Ersatz-Raspi mit FHEM drauf ausgepackt und den zweiten neuen Node als serielles Gateway dran gehangen. Und bums .. der Relais Node wird direkt erkannt und funktioniert einwandfrei. Jedenfalls an dem Ersatz-Raspi. Das einzige was nun anderes ist, ist das ich dem Node eine feste ID verpasst habe. Aber nun bin sicher das die Hardware soweit in Ordnung ist. Heute Abend will ich dieses Node mal versuchen im bestehenden Sensornetzwerk zu starten. Und werde dann nochmal berichten
Wo speichert FHEM eigentlich die vergebenen Node IDs ab ? Laut der Mysensors Doku verwaltet ja der Controller die IDs und nicht das Gateway.

Achso nochwas... Wie kann ich den den Funkkanal und MY_RF24_BASE_RADIO_ID des bestehenden Sensornetzes rausbekommen ?

Gruß

Markus

[Beta-User]

Schön, dass Du vorankommst.

Empfehlung: Nimm die Repeater-Node und scanne damit mal die Kanäle durch (heißt leider nach meiner Kenntnis jedes Mal neu flashen, man kann das im Sketch einstellen), das ist ziemlich sicher ein anderer Kanal, den Du bisher nutzt...

FHEM speichert die ID's nur insoweit ab, als diese als Eigenschaft der einzelnen Devices in der cfg stehen. Das Modul sucht dann bei einem Request schlicht die höchste noch nicht vergebene Nummer und nimmt dann die, mindestens jedoch die 100.

Es ist m.E. sowieso besser, die NodeID fest per Sketch zu vergeben *grins*.

Gruß, Beta-User

[Markus.]

Nur eins verstehe ich Momentan noch nicht so ganz... Ich hab mir ja das serielle Gateway zusammen gesteckt und das komische ist. Meine Sensoren aus dem bestehenden Sensornetz melden sich alle nacheinander auch an diesem Gateway welches ich ja ohne Controller betreibe und nur am USB des Computers angeschlossen habe. Wenn ich ja einen anderen Kanal verwenden würde im bestehenden Sensornetz, dann dürften die sich doch gar nicht melden können oder?
Aber das alles hat einen ungemeinen Lerneffekt 

[Beta-User]

Dann ist es das WLAN-GW, das einen Hau hat (sag ich nicht immer: nehmt ein serielles ).

Den Test kannst Du dann lassen, der Kanal ist iO...

Ich würde den ESP in die Tonne treten und mit dem Seriellen GW weitermachen, aber das ist natürlich Deine Entscheidung .

[Markus.]

so in etwa hab ich das auch gedacht....

[Markus.]

es ist definitiv das Gateway, auf dem seriellen wird direkt alles erkannt und die entsprechenden Datenübertragen.
Meint Test-Serielles-Gateway kann/will ich aber nicht produktiv verwenden, da es ein Arduino Pro Mini ist und ich den angeschlossenen
nrf24l01 pa lna nur mit RF24_PA_MIN laufen lassen kann. Erhöhe ich die Funkleistung ist Ende der Kommunikation. Denke das ist ein Spannungsproblem. Was verwende ich den am besten für Hardware um auch den NRF auf voller Leistung lassen zu können?
Gibt es nicht eine Möglichkeit das Gateway direkt auf dem FHEM Server (intern) laufen zulassen mit dem NRF? Sollte doch irgendwie funktionieren den nrf24l01 pa lna mit dem Raspi zu verbinden??!!
Naja sollte von der Verdrahtung und Konfig nicht allzu kompliziert sein und auch zuverlässig funktionieren..

Gruß

Markus

[Beta-User]

Ich nutze zwischenzeitlich die Adapter-Boards mit Spannungswandler und Kondensatoren drauf am GW. Ein einfacher AMS1117 sollte es aber auch tun (zuammen mit dem obligaten Kondensator).

Nimm evtl. zwischenzeitlich einfach noch eine Repeater-Node in Betrieb, wenn die Reichweite zu gering ist oder teste ein Standardmodul mit höherer Leistung, das hat evtl. dann erst mal eine größere Reichweite, wenn Du die Leistung am besseren Modul nicht weiter erhöhen kannst.

Das mit dem PI-GW geht wohl, ich halte das aber für eine Notlösung (GPIO am PI gehört m.E. für Hausautomatisierung nicht zu den guten Ideen, evtl. abgesehen von den HM-UART-Modulen). Justmy2ct . Und ob der PI genug Saft für diese Art Modul liefert, entzieht sich meiner Kenntnis.

Für den Fall, dass Du Kleinteile brauchst: Bitte melden, min. ein so ein Sockel-Modul kann ich kurzfristig entbehren (mache jetzt RS485 und nutze die Dinger nur noch zum Testen); reine AMS1117 (Transistorbauform) habe ich auch noch ein paar, allerdings weiß ich nicht, ob das dauerhaft thermisch ok ist, wenn man die einfach so verwendet ohne größere Kühlfläche.

[Markus.]

Könnte man nicht den Po Mini einfach an ein FTDI Adapter anschließen ? Eins hab ich noch über, da kann ich eh nun noch mit 3,3 V Ausgang arbeiten. Dann die NRF Spannungsversorgung vom FTDI holen. Weiß nur nicht ob der das auf Dauer mit macht und ob der Spannungswandler auf dem FTDI genug liefert für den NRF.....
Nur so ne Idee..
Weil das soll diesmal vernünftig laufen..

Gruß

Markus

[Beta-User]

Für "erst mal ans Laufen bringen" vermutlich tauglicher Ansatz. Vcc und gnd sollten ja dasselbe Niveau haben.

[Markus.]

Hallo Zusammen,

so das Problem mit der Spannungsvesorgung habe ich soweit im Griff. Also Die Versorgung über den FTDI Adapter hat nicht funktioniert. Anscheinen liefern die weder auf 5 Volt noch auf 3,3v genügend Strom. Was ich nun gemacht habe, ist zum einen Nano (über USB) eingesetzt statt Pro Mini und den NRF über einen Adapter mit Spannungsregler angeschlossen (direkt am 5V Ausgang des Nanos). Als NRF habe ich einen +lna+ pa mit maximaler Sendeleistung. Funktioniert auch soweit erstmal ganz gut. Das Gateway habe ich ausgetauscht, da das alte anscheinend rumgesponnen hat. Die Sende/Empfangsleistung sieht soweit ganz gut aus, 10meter durch vier Wände bei dem ganzen Funkmüll hier. Auf dem NRF hab ich noch einen 10yF Elko (VCC und GND) und das ganze dann auch mit Frischhaltefolie und Alufolie geschirmt.
So nunzum nächsten Schritt. Also funktionieren tut das soweit schon mal nur ein Problem hab ich noch. Wenn ich über FHEM schalte, ist manchmal eine Verzögerung von 3-4 Sekunden bis das Relais schaltet. Man sieht das auch in der seriellen Konsole, das das Signal verzögert am Node ankommt. Wie bekomm ich das denn hin, das der schneller reagiert und halt zuverlässiger wird?

Gruß

Markus

[Beta-User]

Hallo Markus,

mir ist noch nicht so ganz klar, wo die Verzögerung herkommt. Das, was Du schreibst klingt danach, als wäre es evtl. schon FHEM, das die Verzögerung verursacht. Und was heist in dem Zusammenhang zuverlässiger? Forderst Du FHEM-seitig ein ack an, oder gehen Schaltbefehle verloren? Wenn letzteres der Fall ist oder das ack nicht kommt, kann die Verzögerung durch Wiederholungsversuche zustande kommen. Dann wäre evtl. auch ein Repeater in der Mitte der Funkstrecke zweckmäßig (10m+4 Wände sind m.E. - je nach Beschaffenheit - funktechnisch an der Grenze).

Mit einen Repeater könntest Du auf alle Fälle feststellen, ob FHEM schnell versendet und das Problem im Funkbereich liegt, oder ob bereits dort die Denkpase entsteht (dann kann m.E. MySensors nix für).

Gruß, Beta-User