Zwei MySensors Gateways an FHEM-Server

Begonnen von Sweeman, 10 Dezember 2017, 14:04:51

Vorheriges Thema - Nächstes Thema

Sweeman

Hallo Leute,
ich nutze seit einiger Zeit RFM69HCW-Funkmodule (als Ersatz für nRF24 mit mieser Reichweite) für Sensoren und Gateway. Das hat auch bisher ganz gut funktioniert.
Die Adafruit M0 Feather-Boards hatten ein paar Anlaufschwierigkeiten, funktionieren mit kleineren Änderungen aber ganz gut auf der Sensorseite.
Um meinen Stromverbrauch bei den Batteriemodulen zu drücken und die Reichweite noch einmal um einiges zu steigern, habe ich nun LoRa-Module mit dem RFM95 von Moteino/LowPowerLabs besorgt.
Am seriellen Monitor funktioniert alles wunderbar.
Am Pi 3 mit FHEM leider gar nicht. Durch zufall habe ich mal ein paar Werte empfangen, direkt nachdem ich das Gateway über FHEM disconnected und wieder connected habe und nach dem PI reboot über SSH kam auch ein Werte... (nicht reproduzierbar).
Testweise habe ich den Moteino über einen FTDI-Adapter am USB-Port des PIs stecken. Die Baudrate ist 115200 (zu hoch? der Moteino ist 3,3V Atmega328p).
Zunächst möchte ich ausschließen, dass ich etwas in der FHEM-Konfiguration falsch gemacht habe, da ich eher der Typ für die Arduinos und weniger der für FHEM bin ;)
In meiner MySensor.cfg steht folgendes:

# ****************************************************************************
#                           Mysensors (Gateway) 433 MHz
# ****************************************************************************
define MS_G_A005 MYSENSORS /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@115200
attr MS_G_A005 alias MS-G-A005
attr MS_G_A005 autocreate 1
attr MS_G_A005 room Sensoren
attr MS_G_A005 stateFormat connection
attr MS_G_A005 verbose 0

define MYSENSOR_0 MYSENSORS_DEVICE 0
attr MYSENSOR_0 IODev MS_G_A005
attr MYSENSOR_0 mode repeater
attr MYSENSOR_0 version 2.1.1

# ****************************************************************************
#                           Mysensors (Gateway) 868 MHz LoRa
# ****************************************************************************

define MS_G_B001 MYSENSORS /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0@115200
attr MS_G_B001 alias MS-G-B001
attr MS_G_B001 autocreate 1
attr MS_G_B001 room Sensoren
attr MS_G_B001 stateFormat connection
attr MS_G_B001 verbose 0



Mache ich hier schon etwas falsch? Muss ich die Nodes noch besonders zuweisen? Verursacht der MYSENSOR_0 irgendwelche Probleme? Wenn ich es richtig verstehe ist das nur ein Platzhalter, falls ich mal Sensorik am Gateway anschließen möchte...
Seit längerer Zeit hatte mein 433 MHz Gateway anscheinend mal wieder einen Zusammenbruch (es kommen keine neuen Sensorwerte mehr rein). Vermutlich hängt das auch damit zusammen.

Die Devices sind ebenfalls in der MySensors.cfg und sehen so aus:

# ****************************************************************************
#                           Mysensors 433 MHz (B222)
# ****************************************************************************

define MS_S_B222 MYSENSORS_DEVICE 222
attr MS_S_B222 IODev MS_G_A005
attr MS_S_B222 alias MS-S-B222
attr MS_S_B224 mode node
attr MS_S_B224 room Sensoren
attr MS_S_B222 mapReading_current1 1 current
attr MS_S_B222 mapReading_impedance1 1 impedance
attr MS_S_B222 mapReading_temperature 0 temperature
attr MS_S_B222 mapReading_temperature1 1 temperature
attr MS_S_B222 mapReading_temperature10 10 temperature
...
...
...
# ****************************************************************************
#                           Mysensors LoRa 868 MHz (B224)
# ****************************************************************************

define MS_S_B224 MYSENSORS_DEVICE 224
attr MS_S_B224 IODev MS_G_B001
attr MS_S_B224 alias Moteino_224
attr MS_S_B224 mode node
attr MS_S_B224 room Sensoren
...
...
...


Hat schon jemand Erfahrungen mit den LoRas?
Das verrückteste ist, dass das LoRa-Gateway weiter entfernte Sensorik (an einem anderen FHEM-Server mit anderem Gateway) bei deren Reset über das Autocreate aufgenommen hat, obwohl diese RFM69HCW Module mit 433 MHz statt 868 MHz verwenden. Werte wurden allerdings auch von dort nicht erfasst.

Es wäre super, wenn hier jemand etwas Licht in mein Dunkel bringen könnte.
Viele Grüße und Danke im voraus.

Beta-User

Zum eigentlichen Thema kann ich nur dahingehend etwas beitragen, dass ich schon den Fall hatte, dass bei mehreren vorhandenen GW's das falsche IO zugewiesen wurde und ich dann manuell das IODev-Attribut ändern mußte. Bisher war ich aber davon ausgegangen, dass das mit ein paar Dingen zusammenhängt, die hier "speziell" sind - angefangen von der Verwendung derselben IDs (nach Umbau).

Wenn das aber paßt (was ja in erster Linie eine Frage der Übertragungstechnik ist und daher von hier aus nicht beurteilt werden kann), sollte das eigentlich klappen. (Wenn das IO aber falsch ist, bleibt die Node irgendwo bei presentation() hängen, dann kommen auch - ohne Anpassungen - keine Werte).

Vorrangig würde ich als das checken, alternativ mal so einstellen, dass die Node auch ohne Verbindung zum Controller in die loop() gehen (z.B.: #define MY_TRANSPORT_WAIT_READY_MS 3000). Vielleicht kommen dann Werte.
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

Sweeman

Hi Beta-User,
vielen Dank für die Antwort. Die IODevs habe ich zumindest in der MySensor.cfg für die jeweiligen Nodes eingestellt (in diesem Fall MS_G_A005 für 433MHz und MS_G_B001 für das 868 MHz LoRa). Das mit dem Transport_Wait werde ich auf jeden Fall mal ausprobieren. Vielleicht kann man den Fehler dann etwas eingrenzen :)

Beta-User

Nu ja,

dass das direkte Editieren von irgendwelchen cfg's nicht mehr "state of the art" sind, ist hoffentlich bekannt. Nicht dass daher der Wind weht...
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

Sweeman

Zitat von: Beta-User am 10 Dezember 2017, 18:18:30
Nu ja,

dass das direkte Editieren von irgendwelchen cfg's nicht mehr "state of the art" sind, ist hoffentlich bekannt. Nicht dass daher der Wind weht...

Hmm, mal angenommen, dass ich das so mache.. Ich dachte bisher, dass man "normalerweise" die Gatewayadresse im PI mittels "ls /dev/..." ausliest und diese dann in die MySensors.cfg mit dem define einfügt. Das läuft jetzt anders? Die Sensoren lasse ich per autocreate anlegen und "überführe" das dann lediglich von der fhem.cfg in die MySensors.cfg... Das schafft etwas übersicht neben LaCrosse etc.  ???
Ich werde mich gleich mal schlau machen, ob ich da üblen Unsinn verzapfe  ;D Aber du kannst mich auch hier gerne noch mal eines Besseren belehren.  :D

Viele Grüße

Beta-User

Also die Definition "by-id" ist grundsätzlich m.E. die optimale Vorgehensweise dazu.

Das hat aber nichts mit der Frage zu tun, ob man die fhem.cfg (oder irgendwelche includes) "von Hand" editieren sollte oder nicht. Neulich gab es dazu sogar einen Beitrag von Rudi, der meinte, das solle man lassen. Daher die klare Aussage: das ist nicht mehr "state of the art"! Alle Änderungen gehen sinnvollerweise über die Web-Oberfläche, also z.B. durch Klick auf DEF beim GW und dann Eingabe der "by-id"-Adresse. Das mit der Web-Oberfläche geht btw. auch mit includes; dann findet wenigstens noch eine Syntax-Prüfung statt und wohl auch ein automatischer reload.

Früher hatte ich auch mal ca. 10 includes, mittlerweile  ginge das aber eh' nicht mehr, da ich configDB einsetze.

Die Übersicht behält man m.E. einfacher, wenn man die Dinge in Räumen sortiert und sich zum Suchen  anderer Möglichkeiten bedient (angefangen bei "list TYPE=MYS.*").

Der einzige Punkt, auf den man Acht geben sollte, ist IO's zuerst zu definieren, dann niemals zu löschen, sondern allenfalls die DEF zu ändern (oder vorübergehend zu deaktivieren).

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.

Hallo Sweeman,

kannst Du mal Sensor und Gatewaysketch hier rein hängen?
Will das in kürze auch mal versuchen mit den LoRas..

Gruß

Markus