Daten von Nano über I2C an Fhem übermitteln

Begonnen von Mariomgn, 13 August 2017, 10:57:04

Vorheriges Thema - Nächstes Thema

Mariomgn

Hallo,

ich möchte die Daten (Windgeschwindigkeit,Regenmenge) die im Nano verarbeitet werden über I2C an einen Mega mit Ethernetshield welcher für die Steuerung vom Gewächshaus zuständig ist senden.



#I2C
#######################################################################################
# erstes I2c device
define Firmata.ETH3.I2C_1 FRM_I2C 0x68 0 7
attr Firmata.ETH3.I2C_1 IODev FIRMATA.ETH3
attr Firmata.ETH3.I2C_1 event-min-interval 5
attr Firmata.ETH3.I2C_1 group Arduino.ETH3
attr Firmata.ETH3.I2C_1 room System
# zweites I2c device
define Firmata.ETH3.I2C_2 FRM_I2C 105 7 14
attr Firmata.ETH3.I2C_2 IODev FIRMATA.ETH3
attr Firmata.ETH3.I2C_2 event-min-interval 5
attr Firmata.ETH3.I2C_2 group Arduino.ETH3
attr Firmata.ETH3.I2C_2 room System


Der Status von I2C ist defined.



Das ist der Testcode der sich auf dem Nano befindet.

#include <Wire.h>
#include <OneWire.h>
#include <DallasTemperature.h>
#define ONE_WIRE_BUS 2 /* Digitalport Pin 2 definieren */

OneWire ourWire(ONE_WIRE_BUS); /* Ini oneWire instance */

DallasTemperature sensors(&ourWire);/* Dallas Temperature Library für Nutzung der oneWire Library vorbereiten */

union Data
{
  byte asArray[8];
  struct
  {
    unsigned long temp;
    unsigned long Analog_0;
    unsigned long Analog_1;
  };
};

Data values;

void setup()
{
  Wire.begin(1);
Serial.begin(9600);
   
  Wire.onRequest(requestHandler);



  sensors.begin();/* Inizialisieren der Dallas Temperature library */
}

void loop()
{
  sensors.requestTemperatures(); // Temp abfragen

  values.temp=sensors.getTempCByIndex(0);
  values.Analog_0=analogRead(0);
   values.Analog_1=analogRead(1);
}



void requestHandler()
{
  //hier geht nur einmal write() !!
 
  Wire.write(values.asArray, sizeof(values));
}




Habe ich ein Fehler in der Adresse oder im Code vom Nano?

Mfg Mario

klausw

Der FHEM Code sieht erst mal nicht schlecht aus (nur bei den Adressen bin ich nicht sicher ob Hex Werte funktionieren).
Wenn du noch die Attribute 'i2c-config' und 'sampling-interval' im FRM Device konfiguriert hast dann sollte alles passen.

Zu dem Code vom Nano kann ich nicht allzu viel sagen.
Bis auf, das ich keine Definition der I2C Adresse gefunden habe.
Die Wire Bibliothek ist meines Wissens auch nur eine Master Implementierung.
Du möchtest den NAno aber als Slave nutzen.



RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

Mariomgn

Hallo klausw,

danke für deine Antwort.

Wire.begin(1); ist die Stelle wo die Adresse vergeben wird.

void setup()
{
  Wire.begin(1);
Serial.begin(9600);
   
  Wire.onRequest(requestHandler);


Dieser Nano fungiert gerade als Slave. Den Uno welchen ich gerade zum testen mit dem Nano verbunden habe dient als Master.

Die frage ist nur: Sendet FHEM einen Befehl zum Slave und fordert somit die Daten an oder liest FHEM nur?

Was genau meinst du mit
ZitatWenn du noch die Attribute 'i2c-config' und 'sampling-interval' im FRM Device konfiguriert hast dann sollte alles passen.
?


MfG Mario



klausw

Hallo Mario,

zuallererst noch der Hinweis, das ich FRM_I2C nicht nutze und die Informationen aus der commandref habe.


'i2c-config' und 'sampling-interval' sollten im FIRMATA.ETH3 gesetzt sein.
So steht es in der commandref zu FRM_I2C drin.
Ersteres scheint I2C für FRM zu aktivieren.
Der sampling-interval ist der Zeitintervall in dem die Bytes vom I2C abgeholt werden.

Verstehe...
Wire.begin(1);
erzeugt ein Slave Device mit der Adresse 1.

Die 1 ist allerdings, wie ein paar andere auch, reserviert (Bei 0-2 bin ich mir sicher).
Daher kann es sein, das die 1 gar nicht funktioniert.
Anstelle von 0x68 in der FRM_I2C Definition müsstest Du auch die gleiche Adresse verwenden, andernfalls wird dein Slave Device nicht reagieren.

Zitat von: Mariomgn am 15 August 2017, 20:54:41
Die frage ist nur: Sendet FHEM einen Befehl zum Slave und fordert somit die Daten an oder liest FHEM nur?

Vermutlich meinst Du, ob FRM_I2C nur von der I2C-Adresse liest, oder mit Registeradressen arbeitet (also ob Du vor dem lesen einen Schreibzugriff mit der Adresse ausführst).
define <name> FRM_I2C <i2c-address> <register> <bytes-to-read>
sollte diese Frage beantworten.

Ich vermute, das <register> nicht einfach weggelassen werden kann. Somit musst du wahrscheinlich eine Registerfunktion in den Slave einbauen. Es kann natürlich auch sein, das dieses geschriebene Register Byte vom Slave einfach ignoriert wird.

Grüße
Klaus




RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

Mariomgn

Achtung! Ganz blöde frage! ::)

Wo wird das ganze eingebunden? :-\

/* I2C read/write request
* -------------------------------
* 0  START_SYSEX (0xF0) (MIDI System Exclusive)
* 1  I2C_REQUEST (0x76)
* 2  slave address (LSB)
* 3  slave address (MSB) + read/write and address mode bits
      {7: always 0} + {6: reserved} + {5: address mode, 1 means 10-bit mode} +
      {4-3: read/write, 00 => write, 01 => read once, 10 => read continuously, 11 => stop reading} +
      {2-0: slave address MSB in 10-bit mode, not used in 7-bit mode}
* 4  data 0 (LSB)
* 5  data 0 (MSB)
* 6  data 1 (LSB)
* 7  data 1 (MSB)
* ...
* n  END_SYSEX (0xF7)
*/
/* I2C reply
* -------------------------------
* 0  START_SYSEX (0xF0) (MIDI System Exclusive)
* 1  I2C_REPLY (0x77)
* 2  slave address (LSB)
* 3  slave address (MSB)
* 4  register (LSB)
* 5  register (MSB)
* 6  data 0 LSB
* 7  data 0 MSB
* ...
* n  END_SYSEX (0xF7)
*/
/* I2C config
* -------------------------------
* 0  START_SYSEX (0xF0) (MIDI System Exclusive)
* 1  I2C_CONFIG (0x78)
* 2  Delay in microseconds (LSB)
* 3  Delay in microseconds (MSB)
* ... user defined for special cases, etc
* n  END_SYSEX (0xF7)
*/
Sampling Interval
The sampling interval sets how often analog data and i2c data is reported to the client. The default value is 19 milliseconds.
/* Set sampling interval
* -------------------------------
* 0  START_SYSEX (0xF0) (MIDI System Exclusive)
* 1  SAMPLING_INTERVAL (0x7A)
* 2  sampling interval on the millisecond time scale (LSB)
* 3  sampling interval on the millisecond time scale (MSB)
* 4  END_SYSEX (0xF7)
*/


I2C läuft jetzt aaaaber es legt das komplette Fhem lahm und schreibt in´s Log File
Zitat2017.08.16 20:44:07 3: received String_data: I2C: Too few bytes received
Aber es zeigt mir im Reading
ZitatInternals:
   DEF        1 0 2
   IODev      FIRMATA.ETH3
   NAME       Firmata.ETH3.I2C_1
   NR         580
   STATE      active
   TYPE       FRM_I2C
   i2c-address 1
   i2c-bytestoread 2
   i2c-register 0
   Readings:
     2017-08-16 22:48:22   values          16 0
Attributes:
   IODev      FIRMATA.ETH3
   event-min-interval 1
   group      Arduino.ETH3
   room       System
an.

Es werden 2 Bytes gesendet und auch empfangen...

Mariomgn

Kann mir keiner eine Antwort auf die Frage geben? :-\


MfG Mario

klausw

was bedeutet lahm legen?

ist der sampling Intervall zu klein?

Zitat von: Mariomgn am 16 August 2017, 22:51:46
Wo wird das ganze eingebunden? :-\
Geht es um den Arduio Sheet?

Wenn ich z.B. Sampling Interval lese sieht mir das eher nach der Konfiguration eines Masters aus, der zyklisch die Daten auf den I2C rausschickt.
Du willst doch aber einen Slave haben, von dem Du die Daten abholst.
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

Mariomgn

Hallo klausw,

"lahm legen" bedeutet dass das Netzwerk durch zu viele abfragen der Daten irgendwie nur noch sehr langsam reagiert.

Anscheinend wird das in die Configurable Firmata eingebunden aber an welche Stelle genau? Ich habe es versuch aber es kommen dann immer wieder Fehlermeldungen beim Kompilieren.

Ja ich möchte einen Slave. da habe ich wohl etwas übersehen ;D

Mariomgn

Hallo klausw,

kannst du mir bitte sagen wo ich den Sampling Interval einstellen muss und was es mit den V2.3 Protocol auf sich hat?

Ich habe mir eben mal die Doku vom Firmata Protokoll angeschaut (https://github.com/firmata/protocol) ich werde aber daraus nicht ganz schlau...

Eigentlich kann es doch nicht so schwer sein eine Kommunikation zwischen einem Arduino Mega mit meinem Programm für die Bewässerung und dem Mega mit der Configurable Firmata herzustellen... Bei zwei Mega habe ich schon eine Multimaster Kommunikation realisiert, mein Problem liegt eigentlich nur an dieser Cofigurable Firmata.


MfG Mario 

jensb

Hallo Mario,

mir geht es wie Klaus, mit FRM_I2C habe ich selbst noch nicht gearbeitet.

ZitatEigentlich kann es doch nicht so schwer sein eine Kommunikation zwischen einem Arduino Mega mit meinem Programm für die Bewässerung und dem Mega mit der Configurable Firmata herzustellen... Bei zwei Mega habe ich schon eine Multimaster Kommunikation realisiert, mein Problem liegt eigentlich nur an dieser Cofigurable Firmata.
Wenn man davon ausgehen kann, dass du einen Arduino Nano mit I2C über einen Mega mit LAN mit FHEM per Netzwerk verbinden willst, dann brauchst du ein Kommunikationsprotokoll, das beide Seiten beherrschen. Firmata ist dabei eines von mehreren, die dafür in Frage kommen. Firmata ist kein I2C-Protkoll, kann aber u.a. I2C-Befehle über USB bzw. TCP/IP übertragen. Der Arduino Mega ist dabei Firmata Slave und I2C Master, FHEM Firmata Master. Mit Firmata brauchst du kein eigenes Programm für den Arduino Mega. Um das Firmata Protokoll brauchst du dich dann auch nicht mehr zu kümmern. Es ist aber möglich, Firmata um eigene Programmteile zu erweitern. Auf den Arduino Nano implementierst du einen I2C-Slave.

Wenn ich mir den Thread so durchlese, bin ich mir aber nicht ganz sicher, ob du auf dem Mega schon Firmata hast. Wenn nein, dann installiere auf dem Mega zuerst entweder Firmata (Version egal) oder ConfigurableFirmata bis Version 2.6 (z.B. Beispiel StandardFirmataEthernet aus der Arduino-IDE nehmen und Netzwerkparameter konfigurieren). Kompilieren sollte mit dem Mega kein Problem sein. ConfigurableFirmata ab Version 2.7 funktioniert momentan ohne Modifikation nicht mit FHEM. Diese Modifikationen sind schon mehrfach im Forum diskutiert worden.

Das "sampling-interval" ist ein Attribut des FRM-Moduls in Millisekunden (Commandref). Hier solltest du mit Werten um 10000 anfangen und dann ggf. kleiner werden.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

Mariomgn

Hallo jensb,

danke für deine Antwort.

Aktuell habe ich auf 4 Mega´s die Configurable Firmata mehr oder weniger Stabil laufen...

Dann gibt es z.b. im Garten einen Schaltschrank mit dem Mega Garten der über Netzwerkkabel-Switch- mit dem Raspberry pi verbunden ist.
Dieser Mega Kommuniziert momentan über IO Pins mit dem Mega Bewässerung welcher mit meinem Programm läuft und zuständig ist für die Wasserversorgung von Garten,Gewächshaus,Garage und auch selbstständig den Wasserzulauf aus der Dachrinne abhängig von dem Füllstand der Wasserfässer regelt.

Momentan habe ich das Problem dass ich gerne den Aktuellen Füllstand der Fässer vom Mega Bewässerung  in FHEM anzeigen lassen möchte und auch diesen Kabelsalat zwischen den beiden Mega´s beseitigen und die Kommunikation komplett über i2c realisieren.

Das Ganze dann auch im Haus, Garage und Gewächshaus.



Mfg Mario

jensb

Hallo Mario,

wenn ich das richtige verstehe, benötigen die Megas die Sensordaten zum Arbeiten, aber sie sollen auch auf FHEM zur Verfügung gestellt werden. Die I2C-Verkabelung der Megas untereinander spart Drähte, muss aber gut geschirmt werden. Alternativ käme z.B. RS-485 in Frage, das braucht sogar nur 2 Leitungen und kann auch mehr als 2 Teilnehmer.

Firmata ist ohne Modifikationen nicht dazu geeignet, eigene Variablen zum Master zu übertragen, denn die Idee hinter Firmata ist, die I/Os des Slave direkt am Master verfügbar zu machen und alles auf dem Master zu machen. Wenn du also auch auf den Arduinos Logik hast, passt das so nicht.

Baue dein Arduino-Netz so auf, dass es autonom arbeitet. Für die Verbindung mit FHEM würde ich einen Blick auf MQTT werfen. Mit publish kannst du die Sensordaten an FHEM verschicken und mit subscribe Steuerwerte einlesen. Alternativ kannst du aber auch ein eigenes Protokoll definieren und auf FHEM-Seite z.B. ECMD verwenden.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

Mariomgn

Hallo Jens,

Ist RS-485 sowas wie CAN Bus?

Hast du mit RS-485 schon Erfahrungen?

Wenn man für I2C wirklich etwas an der Firmata ändern muss gebe ich hier auf denn das habe ich schon versucht... 20 schwerwiegende Fehler mit nur einer kleinen Änderung  8)

MfG Mario

jensb

Hallo Mario,

ZitatIst RS-485 sowas wie CAN Bus?
Beides sind 2-Draht-Busse, die im Gegensatz zu I2C für größere Kabellängen ausgelegt sind. CAN definiert zusätzlich ein Protokoll, RS-485 ist "nur" ein Hardware-Schnittstellenstandard. CAN würde ich für dein Projekt als oversized einstufen.

ZitatHast du mit RS-485 schon Erfahrungen?
Ja, als Anwender aber nicht als Entwickler. Die Einbindung von RS-485 ist bei Arduinos aber kein Problem. Du brauchst jeweils ein Transceiver-Modul. Nimm eine Suchmaschine deiner Wahl, dann findest du Beispiele für den Hardware-Aufbau und die Software.

ZitatWenn man für I2C wirklich etwas an der Firmata ändern muss ...
Nur um es klarzustellen: Für I2C muss man nichts an Firmata ändern - aber um eigene Variablen über das Firmata-Protokoll zu übertragen muss man die Standard-Firmata-Beispiele anpassen.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

Mariomgn

Hallo Jens,

habe mir das ganze gerade mal angeschaut.

Ich habe irgendwie ein Problem damit, extra Bauteile zu verbauen :-\

""NEUE IDEE""

Kommunikation über Serial.read/.write zwischen den Mega´s!?

Benötigt werden da drei Kabel und es wäre auch in beide Richtungen möglich.

Was meinst du dazu?

Im Forum und bei google habe ich danach gesucht aber auch nur von 2011 eine nicht beantwortete frage gefunden  :-\

MfG Mario