Hauptmenü

Relais Steuerung

Begonnen von Markus., 13 August 2017, 18:18:30

Vorheriges Thema - Nächstes Thema

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:
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
#define MY_TRANSPORT_WAIT_READY_MS 3000zu lösen.
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

Markus.

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



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

Zitat von: Markus. am 15 August 2017, 13:46:30
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).
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

Markus.

Ja der Loop sieht nun wie folgt aus


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


#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 ;) .
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

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

Markus.

#23
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 8) .

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

Markus.

#25
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



/*
* 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
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

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 ;D 8) ::) .
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

Markus.

so in etwa hab ich das auch gedacht.... :-)