Integration von MySensors in FHEM geplant?

Begonnen von fh555, 06 September 2014, 00:40:58

Vorheriges Thema - Nächstes Thema

presskopf

Aaah, again what learned!

Habe die Boardverwalter 1.6.10 auf IDE 1.6.10 installiert.
Leider kein Unterschied...  :(


Beta-User

Hmmm...

Soweit ich das verstehe, hat er ein Problem damit, dass vermeintlich die Senderoutine nicht existiert (in Norberts Variante steht die in Zeile 411 der 00_MYSENSORS.pm).

Kannst Du mal nachsehen, ob evtl. die .pm kaputt ist? (Rechte passen? (fhem:dialout)). Wenn das der Fall ist: ggf. mal mit wget https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/00_MYSENSORS.pm?format=raw (aus dem richtigen Verzeichnis heraus, Rechte wieder anpassen) neu installieren (oder gleich als Tester für die erweiterten Versionen von Hauswart bewerben)???
(
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

presskopf

Habe die Datei vom github runtergeladen und verglichen.
Bis auf das return undef; ist alles identisch. Das habe ich damals eingebaut, um ein Gateway auch wieder löschen zukönnen.

root@raspi-4:~# diff 00_MYSENSORS.pm /opt/fhem/FHEM/00_MYSENSORS.pm
116a117
>   return undef;
root@raspi-4:~#


Mein Bauch sagt, da liegt bei meiner Installation irgendwas im Argen - obwohl ansonsten alles fluppt...

Beta-User

Irgendwie gehen mir jetzt auch die Ideen aus :(.

Die beiden Devices hast Du sicher auch schon mal gelöscht und wieder anlegen lassen, oder?

Und was ist das für eine ZE.batterie, was da im log steht und die loop auslöst? Jedenfalls in dem verlinkten PIR-lux-sketch wird ja kein batterie-reading mit übertragen. Vielleicht könntest Du da die Child_ID_Light auf was anderes als "0" festlegen. (Ich verwende die in der Regel für "interne" Zwecke, das erste echte Child bekommt die "1" oder höher; sollte eigentlich nicht schaden, aber wer weiß...).
Wenn irgendwo ZE.batterie für ein notify usw. genutzt wird, müßte es unten bei "probably associated with..." auftauchen?
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

presskopf

ZE.Batterie habe ich hier geklaut; glaube kaum, dass es damit zu tun hat.
http://www.meintechblog.de/2015/08/fhem-rechtzeitige-benachrichtigung-bei-leeren-batterien/

Ich habe mal auf die Schnelle ein Serial Gateway mit FTDI-Nano und NRF24-Sender zusammengebaut.
Wieder mit 1.6.10 kompiliert und geflasht.

Unglaublich, das bringt mein FHEM ebenfalls zum Crash!   :o

Das Log ist aber deutlich umfangreicher:
2016.12.05 17:18:25 5: MYSENSORS/RAW: /0;2
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;2/55;3;0;9;TSP:MSG:READ 27-27-255 s=
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:READ 27-27-255 s=/255,c=3,t=7,pt=0
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:READ 27-27-255 s=255,c=3,t=7,pt=0/,l=0,sg=0:
0;255
2016.12.05 17:18:25 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 'TSP:MSG:READ 27-27-255 s=255,c=3,t=7,pt=0,l=0,sg=0:'

2016.12.05 17:18:25 5: MYSENSORS gateway gateway_serial: TSP:MSG:READ 27-27-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;255/;3;0;9;TSP:MSG:B
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:B/C
0;255;3;0;9;TS
2016.12.05 17:18:25 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 'TSP:MSG:BC'

2016.12.05 17:18:25 5: MYSENSORS gateway gateway_serial: TSP:MSG:BC
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;255;3;0;9;TS/P:MSG:FPAR REQ (
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:FPAR REQ (/sender=27)
0;2
2016.12.05 17:18:25 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 'TSP:MSG:FPAR REQ (sender=27)'

2016.12.05 17:18:25 5: MYSENSORS gateway gateway_serial: TSP:MSG:FPAR REQ (sender=27)
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;2/55;3;0;9;TSP:CHKUP
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:CHKUP/L:OK
0;255;3;0;
2016.12.05 17:18:25 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 'TSP:CHKUPL:OK'

2016.12.05 17:18:25 5: MYSENSORS gateway gateway_serial: TSP:CHKUPL:OK
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;255;3;0;/9;TSP:MSG:GWL OK

2016.12.05 17:18:25 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 'TSP:MSG:GWL OK'

2016.12.05 17:18:25 5: MYSENSORS gateway gateway_serial: TSP:MSG:GWL OK
2016.12.05 17:18:25 5: MYSENSORS/RAW: /0;255;3;0;
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;255;3;0;/9;TSP:MSG:SEND 0-0
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:SEND 0-0/-27-27 s=255,c=3
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:SEND 0-0-27-27 s=255,c=3/,t=8,pt=1,l=1,sg=0
2016.12.05 17:18:25 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:SEND 0-0-27-27 s=255,c=3,t=8,pt=1,l=1,sg=0/,ft=0,st=ok:0

2016.12.05 17:18:25 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 'TSP:MSG:SEND 0-0-27-27 s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=ok:0'

2016.12.05 17:18:25 5: MYSENSORS gateway gateway_serial: TSP:MSG:SEND 0-0-27-27 s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=ok:0
2016.12.05 17:18:27 5: MYSENSORS/RAW: /0;255;3;0;
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;/9;TSP:MSG:READ 2
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:READ 2/7-27-0 s=255,c=3,t
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:READ 27-27-0 s=255,c=3,t/=24,pt=1,l=1,sg=
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:READ 27-27-0 s=255,c=3,t=24,pt=1,l=1,sg=/0:1
0;255;3;0;9;
2016.12.05 17:18:27 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 'TSP:MSG:READ 27-27-0 s=255,c=3,t=24,pt=1,l=1,sg=0:1'

2016.12.05 17:18:27 5: MYSENSORS gateway gateway_serial: TSP:MSG:READ 27-27-0 s=255,c=3,t=24,pt=1,l=1,sg=0:1
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;/TSP:MSG:PINGED (
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:PINGED (/ID=27, hops=1)

2016.12.05 17:18:27 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 'TSP:MSG:PINGED (ID=27, hops=1)'

2016.12.05 17:18:27 5: MYSENSORS gateway gateway_serial: TSP:MSG:PINGED (ID=27, hops=1)
2016.12.05 17:18:27 5: MYSENSORS/RAW: /0;255;3;0
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0/;9;TSP:MSG:SEND 0-
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:SEND 0-/0-27-27 s=255,c=
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:SEND 0-0-27-27 s=255,c=/3,t=25,pt=1,l=1,
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:SEND 0-0-27-27 s=255,c=3,t=25,pt=1,l=1,/sg=0,ft=0,st=ok:1

2016.12.05 17:18:27 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 'TSP:MSG:SEND 0-0-27-27 s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=ok:1'

2016.12.05 17:18:27 5: MYSENSORS gateway gateway_serial: TSP:MSG:SEND 0-0-27-27 s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=ok:1
2016.12.05 17:18:27 5: MYSENSORS/RAW: /0;2
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;2/55;3;0;9;TSP:MSG
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG/:READ 27-27-0 s=25
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:READ 27-27-0 s=25/5,c=3,t=15,pt=6,
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:READ 27-27-0 s=255,c=3,t=15,pt=6,/l=2,sg=0:0100

2016.12.05 17:18:27 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 'TSP:MSG:READ 27-27-0 s=255,c=3,t=15,pt=6,l=2,sg=0:0100'

2016.12.05 17:18:27 5: MYSENSORS gateway gateway_serial: TSP:MSG:READ 27-27-0 s=255,c=3,t=15,pt=6,l=2,sg=0:0100
2016.12.05 17:18:27 5: MYSENSORS/RAW: /0;255;3;0;
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;/9;!TSP:MSG:SEND
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;!TSP:MSG:SEND /0-0-27-27 s=255,
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;!TSP:MSG:SEND 0-0-27-27 s=255,/c=3,t=15,pt=6,l=2,
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;!TSP:MSG:SEND 0-0-27-27 s=255,c=3,t=15,pt=6,l=2,/sg=0,ft=0,st=fai
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;!TSP:MSG:SEND 0-0-27-27 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=fai/l:0100

2016.12.05 17:18:27 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '!TSP:MSG:SEND 0-0-27-27 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=fail:0100'

2016.12.05 17:18:27 5: MYSENSORS gateway gateway_serial: !TSP:MSG:SEND 0-0-27-27 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=fail:0100
2016.12.05 17:18:27 5: MYSENSORS/RAW: /0
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0/;255;3;0;9;TSP:M
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:M/SG:READ 27-27-0
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:READ 27-27-0 /s=255,c=3,t=6,pt=1
2016.12.05 17:18:27 5: MYSENSORS/RAW: 0;255;3;0;9;TSP:MSG:READ 27-27-0 s=255,c=3,t=6,pt=1/,l=1,sg=0:0
2
2016.12.05 17:18:27 5: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 'TSP:MSG:READ 27-27-0 s=255,c=3,t=6,pt=1,l=1,sg=0:0'

2016.12.05 17:18:27 5: MYSENSORS gateway gateway_serial: TSP:MSG:READ 27-27-0 s=255,c=3,t=6,pt=1,l=1,sg=0:0
2016.12.05 17:18:27 5: MYSENSORS/RAW: 2/7;255;3;0;6;0

2016.12.05 17:18:27 5: MYSENSORS Read: Rx: fr=027 ci=255 c=003(C_INTERNAL    ) st=006(I_CONFIG        ) ack=0 '0'

2016.12.05 17:18:27 5: Triggering MYSENSOR_27 (1 changes)
2016.12.05 17:18:27 5: Notify loop for MYSENSOR_27 parentId: 0
2016.12.05 17:18:27 5: ZE.Batterie: not on any display, ignoring notify
Undefined subroutine &MYSENSORS::DEVICE::sendMessage called at ./FHEM/10_MYSENSORS_DEVICE.pm line 560.


Das mit der CHILD_ID teste ich später noch...

Beta-User

Zitat von: presskopf am 05 Dezember 2016, 17:21:30
ZE.Batterie habe ich hier geklaut; glaube kaum, dass es damit zu tun hat.
..keine Ahnung, aber das ist das letzte, was im log erscheint. Ich würde die mal einfach zur Sicherheit rausnehmen...

Für mich sieht das auch eher so aus, als wäre es ein FHEM-Problem und nicht eines, was speziell mit MySensors zu tun hat, ist aber auch nur ein Bauchgefühl. (Einer meiner 2.0.0-beta-Sensoren sendet auch regelmäßig ein Battery-Reading, an sich stellt das Reading für sich m.E. kein Problem dar und welche Version, ist auch egal, das Protokoll ist over-the air und seriell nicht geändert, es sind nur neue Readings/Mechanismen dazugekommen; diese werden aber bei den einfachen Sketches noch gar nicht genutzt...).

Was Deine Infrastruktur angeht: An sich ist vermutlich nicht schädlich, was Du verwendest, ich würde aber dennoch eher mal die IDE auf den aktuellen Stand bringen, die Board-Definitionen aber auf 1.6.11 lassen (v.a. auch für das serielle GW, das hat dasselbe Reboot-Problem) und die aktuelle MySensors-beta nehmen (2.1.0-beta).
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

presskopf

#996
Vielen Dank für Deine Hilfe @Beta-User !

Es sieht wohl so aus, dass ich, nachdem ich alle Arduino-IDEs, Boardverwalterversionen und Mysensor-branches durchgetestet habe, es wieder stabil habe.
Dein Riecher, dass es FHEM-spezifisch ist, war richtig. Während meines Upgrade des Gateways von 1.5.4 auf 2.0 habe ich das Gateway neu angelegt. Da ein erneutes Anstöpsel sowie ein Neustart das 2.0er Gateway nicht erkannt hat. Den Rest der Mysensors-Defines habe ich nicht angerührt.
Das führte dazu, dass das Gateway nach den Nodes in der fhem.cfg auftaucht, welches dieses seltsame Verhalten anscheinend herbeiführt.
Richtig wäre wohl gewesen:

a) Alle Nodes löschen und neu anlegen
oder
b) In die fhem.cfg eingreifen und den Gateway-Eintrag hochschieben - wie nun getan.

Au Mann, damit kann man zwei Tage verbringen.... >:(

Frage: Wie machen das die Kollegen mit config.db?

Beta-User

Schön, dass jetzt alles wieder läuft!

Zitat von: presskopf am 05 Dezember 2016, 19:50:59
Frage: Wie machen das die Kollegen mit config.db?
Zu configDB@sqlite kann ich nur folgende Erfahrungen liefern (ist hier aber etwas off-topic):
- Umgestellt irgendwann im Frühjahr, der "Bestand" entsprach in etwa dem heutigen, seither wurden eher nur marginale Dinge geändert.
- Vor dem Umstieg hatte ich eine ganze Reihe von includes (Erst die grundsätzlichen Dinge (global usw.) , dann I/O's, dann die "externe" HW nach Typen (HM-Heizung, HM-Rest, MySensors, Milight), dann erst die Logikelemente, um die Übersicht zu behalten und ggf. einfacher wieder was zurückspielen zu können (s.u.)).
- Anlaß für die Umstellung war eine Diskussion mit betateilchen und Cooltux, die der Ansicht waren, dass configDB gerade für "schlichte user" viel unproblematischer sei als das mit den includes, die (vor meiner Rückfrage dazu bereits) intensive Diskussion zwischen den Beiden war nach meiner Erinnerung veranlaßt gewesen durch gerade so ein Reihenfolgethema wie bei Dir ;). Ich hatte das als "Versprechen" verstanden, mich mit solchen Dingen nicht mehr beschäftigen zu müssen (was aber unproblematisch war, da ich ja wußte, in welcher Reihenfolge man die Abhängigkeiten auflösen muß).
- Bisher gab es gefühlt keine Probleme, die auf derartige Reihenfolgethemen wie jetzt aktuell bei Dir zurückzuführen gewesen wären
- Positiv vermerkt habe ich, dass scheinbar Devices, die früher gelöscht gewesen wären (insbes. DS18B20 via USB-OWX) automatisch wieder auftauchten, sobald sie angestöpselt waren. Zuvor hatte ich bei diesen mehrfach den Fall gehabt, dass diese durch ein "save" zum falschen Zeitpunkt gelöscht worden waren und ich die entsprechenden Abschnitte der includes wieder herstellen mußte.
- Probleme dahingehend, dass die DB zu groß würde (über das Problem hatten andere berichtet), habe ich nicht, ca. 32 MB (was im Vergleich zu Textfiles natürlich immer noch riesig ist...)
- Da es die Option gibt, sich eine aktuelle *.cfg als Textfile zu exportieren, mache ich das als Backup hin und wieder und sehe configDB ansonsten als unproblematisch an (auch wenn ich nach wie vor keinen Schimmer habe, was da im Detail passiert).

Wenn Du Fragen zur wirklichen Funktionalität von configDB hast, ist vermutlich betateilchen der richtige Ansprechpartner.
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

Hauswart

@presskopf Die Fehlerkonstellation bei dir ist mir immer noch etwas rätselhaft... aber gut es läuft wieder :D
1. Installation:
KNX, Tasmota (KNX), Sonos, Unifi

2. Installation:
HM-CFG-USB, Unifi (, SIGNALduino 868, MySensors, SIGNALduino 433)

kleinerDrache

Ich verwende ConfigDB (MySQL) soweit ich mich erinnere musste ich damals als ich nach dem Gateway löschen gefragt hatte (und der erfolgreich gelöscht war) auch erst alle noch vorhandenen Reste von MySensors entfernen bevor ich den Gateway neu angelegt habe ,weil mir sonst immer FHEM gecrasht war. Also IMMER den Gateway als erstes im System wie ich das sehe. Ich weis dann bloß nicht wie das ist wenn ich mal nen neuen Gateway einbaue und danach den alten entferne(warum auch immer ;) )?
Raspi 2 - Hmusb2 , 2xJeeLink , EnOcean pi: Serie14 Geräte , 6xHM-Sec-Rhs , 6xHM-CC-RT-DN, verschiedene MySensor Nodes, ein bischen MQTT

PeMue

Hallo,

so, jetzt habe ich mal meinen zweiten SensebenderMicro auf die library v2.0 aktualisiert und - siehe da - er hört nicht mehr nach ein paar Tagen auf. Die leeren Batterien kann ich auch nicht erklären.
Sei's drum, wenn es funktioniert, soll es gut sein. Jetzt muss ich nur noch den Sketch so umbauen, dass er ganz am Anfang die Versorgungsspannung mitschickt und mal einen Referenzsensor daneben stellen, um zu sehen, wie genau die Dinger messen.

Gruß PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

Beta-User

Zitat von: PeMue am 06 Dezember 2016, 21:41:31
Jetzt muss ich nur noch den Sketch so umbauen, dass er ganz am Anfang die Versorgungsspannung mitschickt
Moin,

mit der aktuellen 2.1.0-beta geht das recht simpel: Einfach den Sendebefehl zu dem entsprechenden Meßwert in der setup()-Routine unterbringen.
Soweit ich das auf Github gelesen habe, soll die 2.1.0 eine Weihnachtsedition werden, die Codebasis dürfte daher eher einen ziemlich stabilen Zustand erreicht haben... Das hat btw. auch den Vorteil, dass man seitens des Controllers theoretisch das setup() auch erneut ausführen lassen kann, also solche Infos dann bei Bedarf aktiv erfragen könnte.

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

jnewton957

#1002
Hallo,

ich versuche mich aktuell auch mit mysensors sensoren. Dazu habe ich mir 8 MQ-X Sensoren für unterschiedliche Gasarten besorgt.

Wie schaffe ich es, mehrere SENSOREN verwenden zu können. Ich möchte ja nicht z.b. nano und MQ-SENSOR JEWEILS 1:1 aufbauen zu müssen. Wären ja bis zu 8 nano.

Wie bekomme ich also z.b. Luftqualität und co2 oder sagen wir mal 4 Sensoren zu laufen?
Da muss ich doch sicherlich mit ext. Netzteilen für power der Sensoren arbeiten. Über den power pin des nano oder mega dürfte ja wegen der Ampere den nano zerstören.
Welches Netzteil?


Grüße
Jörg

FHEM6.2 auf Pi5
V 1.66 nanoCUL 433 (IT)
V 1.66 nanoCUL868 (HM)
sqlite3 LogDb
ELRO AB440, DECT200,  TFA30.3125, esp8266, HM, TabletUI, IR-Schreiblesekopf (Udo),tibber Pulse, Kostal Pico, cfos Wallbox, Modbus TCP

Beta-User

...da sich sonst keiner zu trauen scheint...

...zu Stromhunger kann ich nichts sagen ::), vermutlich solltest Du ein Netzteil nehmen, das so angeschlossen werden kann, dass die MQ-x-e direkt (ohne 5V/Ground-Anschluß am Arduino) bedient werden können; unmöglich sollte das vom Gesamtverbrauch her nicht sein, schließlich steht da im Sketch irgendwo was von Batteriebetrieb; evtl. könnte man die einzelnen Sensoren über einen Transistor ein- und ausschalten...

Was das Anschließen angeht, wird pro MQ-x je ein analoger Meßwert erfaßt, dann umgerechnet und übertragen, wenn ich das richtig verstanden habe. Damit sollten (wenn der Speicher reicht) pro Arduino auch 6 MQ-x-e angeschlossen werden können. Es müßte m.E.
- der jeweilige Analog-Pin angepasst werden
- Die Umrechung ist für alle gleich? Diese dann evtl. in eine extra Routine auslagern, sonst halt jeweils angepaßt...
- die Werte sollten vermutlich intern am besten über einen Index und entsprechende Arrays erfaßt bzw. gespeichert und übermittelt werden  (ähnlich dem DS18B20-Sketch für mehrere Sensoren). Dazu würde ich nicht mit "0" anfangen, sondern mit "1" (weil FHEM die "0" dann wieder bei der Benennung der Readings unterschlägt).

Wenn das zu kurz oder kryptisch war, bitte melden.

Gruß und guten Rutsch,

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

kleinerDrache

ohm sorry garnet gesehen *gg*

Für die Gassensoren UNBEDINGT entweder direkt an die Batterie gehen oder per Netzteil und IMMER mit nem Transistor schalten die Dinger verbraten einiges an mA an Strom (einige über 100) und davon kann der
Arduino an den Pins nur INSGESAMMT in Summe für alles maximal glaube ca 40 mA liefern. Aber denke eher mit Netzteil da die Sensoren der MQ Reihe alle mit einer Heizung für die Gase arbeiten und diese eine bestimmte Zeit braucht bis da halbwegs stabile Werte rauskommen. Ansonsten kann ich Beta nur zustimmen.
Raspi 2 - Hmusb2 , 2xJeeLink , EnOcean pi: Serie14 Geräte , 6xHM-Sec-Rhs , 6xHM-CC-RT-DN, verschiedene MySensor Nodes, ein bischen MQTT