Firmata mit MCP23017

Begonnen von beSmart, 08 April 2018, 14:16:41

Vorheriges Thema - Nächstes Thema

R1F800

Zitat von: jensb am 09 März 2019, 22:17:05
Verstehe ich das richtig? Du kannst mit FRM_I2C auf das LCD-Display schreiben, aber nicht lesen?

Hast du vielleicht eine Mischung von 3,3V und 5,0V Busteilnehmern?

Jab. Schreiben auf den I2C Bus ist kein Problem, die Daten kommen auf dem LCD an. LCD Commands laufen alle reibungslos.

Eine Mischung ist eigentlich ausgeschlossen. I2C Teilnehmer:

1) Nano
2) LCD
3) MCP23017

jensb

ZitatEine Mischung ist eigentlich ausgeschlossen.
Es gibt verschiedene Nanos für verschiedene Betriebsspannungen. Die tatsächliche Betriebsspannung steht manchmal auf dem Modul und lässt sich bei Bedarf nachmessen.
Der MCP23017 passt sich an seine Versorgungsspannung an.

Hast du inzwischen mal versucht mit einem Arduino-Sketch ohne Firmata von einem der I2C-Devices zu lesen?
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

R1F800

Zitat von: jensb am 16 März 2019, 20:47:24
...

Hast du inzwischen mal versucht mit einem Arduino-Sketch ohne Firmata von einem der I2C-Devices zu lesen?

Nein, das habe ich noch nicht probiert. 
Kannst Du mir mal bitte einen passenden Sketch, den Du gerade im Kopf hast benennen?
Dann kann ich das recht flux testen

jensb

Ich habe keinen "passenden" Sketch. Nimm ein Beispiel für I2C aus der Arduino-IDE und passe es so an, dass sowohl etwas geschrieben als auch gelesen wird. Das Geschriebene kannst du über das I2C-Device überprüfen. Das Gelesene musst du dann im Arduino bewerten und bei gut z.B. eine LED oder zumindest einen Ausgang an machen.
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

R1F800

Zitat von: jensb am 17 März 2019, 18:58:00
Ich habe keinen "passenden" Sketch. Nimm ein Beispiel für I2C aus der Arduino-IDE und passe es so an, dass sowohl etwas geschrieben als auch gelesen wird. Das Geschriebene kannst du über das I2C-Device überprüfen. Das Gelesene musst du dann im Arduino bewerten und bei gut z.B. eine LED oder zumindest einen Ausgang an machen.

verstehe ich das dann richtig. Ich baue mir manuell einen Sketcht mit den Bibliothelken I2C und Ethernet zusammen ?
Ich verstehe gerade den Ansatz nicht, was Du genau flashen willst und wie der Testprozess aussehen soll. IOs ist klar (Arduino <I2C> MCP230017)
Aber wie soll der Arduino angesprochen werden?

jensb

Du bekommst keine Daten über I2C gelesen, weißt aber nicht warum. Das Ethernet-Modul spielt bei diesem Problem keine Rolle. Mögliche Fehlerquellen sind die Hardware (Arduino, MCP) und die Firmware (Firmata).

Wenn du wissen willst, ob man mit deinem Arduino über I2C vom MCP lesen kann, dann musst du einen minimalen Sketch ohne Firmata bauen, der genau das prüft und nicht mehr.

Dazu muss der Sketch nicht von außen angesprochen werden. Es genügt eine fest programmierte Sequenz, die irgendetwas macht, das man überprüfen kann. Dafür eignet sich z.B. bei I2C ein Register, dass immer einen bekannten Wert hat, den man dann abfragt und wenn passend eine LED oder einen Ausgang setzt.
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

R1F800

OK.
Dann bin ich da ab diesem Punkt raus :-) meine Mikrokontroller habe ich bisher mit BASCOM bespielt, aber alles was dann in andere Sprachen geht (C etc.) bin ich raus.
Ich weis, dass ich bei meinem MCP und dem ESP auch Probleme hatte ... die Biester sind auf dem I2C ziemlich empfindlich ...

Ich versuche mal Deinen Tip zu testen .. wird aber wohl an meinen Kompetenzen scheitern ... (kein Cobol, Bascom oder Assembler oder DB2/DL1 :-) )

jensb

Sorry, wenn C nicht dein Ding ist.

Die Wahrscheinlichkeit eines Firmata- oder FHEM-Bugs ist hier sehr klein. Wenn du kein Zugang zu einem DSO hast, bleiben fast nur noch Tests mit der Firmware.

Du könntet aber versuchsweise einen ESP8266 statt des Arduinos verwenden. Damit kannst du WiFi statt Ethernet für die Verbindung mit FHEM verwenden. Firmata läuft nämlich auch auf dem ESP8266. Mit dem ESP8266 könntest du feststellen, ob dein MCP überhaupt antwortet. Der ESP8266 bevorzugt allerdings 3,3V.

Alternativ könntest du auf dem ESP8266 mit NodeMCU statt Firmata verwenden, dann kommst du ohne C aus.

Du hast noch die Option, sowohl den Nano als auch den MCP gegen neue Komponenten zu tauschen unter der Annahme, dass einer oder beide defekt sind. Das würde ich aber als allerletztes machen. Wenn du ein Verdrahtungsproblem hast, könntest du dir sonst den 2. Satz ebenfalls beschädigen.
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

R1F800

Zitat von: jensb am 19 März 2019, 19:44:09
Sorry, wenn C nicht dein Ding ist.

Die Wahrscheinlichkeit eines Firmata- oder FHEM-Bugs ist hier sehr klein. Wenn du kein Zugang zu einem DSO hast, bleiben fast nur noch Tests mit der Firmware.

Du könntet aber versuchsweise einen ESP8266 statt des Arduinos verwenden. Damit kannst du WiFi statt Ethernet für die Verbindung mit FHEM verwenden. Firmata läuft nämlich auch auf dem ESP8266. Mit dem ESP8266 könntest du feststellen, ob dein MCP überhaupt antwortet. Der ESP8266 bevorzugt allerdings 3,3V.

Alternativ könntest du auf dem ESP8266 mit NodeMCU statt Firmata verwenden, dann kommst du ohne C aus.

Du hast noch die Option, sowohl den Nano als auch den MCP gegen neue Komponenten zu tauschen unter der Annahme, dass einer oder beide defekt sind. Das würde ich aber als allerletztes machen. Wenn du ein Verdrahtungsproblem hast, könntest du dir sonst den 2. Satz ebenfalls beschädigen.

ups .. vollkommen überlesen; den Portexpander habe ich alternativlos erstmal gestrichen gehabt ... leider

Also das Problem besteht weiterhin...
Ein ESP8266 mit Versorgungsspannung 5V läuft stabil mit ESPeasy der MCP kann fehlerfrei angesprochen werden. vielleicht mal via FIRMATA einen bestehenden ansprechen ?


R1F800

So ...
in diesen Zeiten hat man auch mal wieder Zeit sich um vernachlässigte Themen zu kümmern ....

Also der MCP23017 funktioniert nun am arduino nano 328p mit configFirmata.

ABER
ich habe bis jetzt noch keine Interuptleitung auf den nano, dass ich dann den PINLEVEL zum aktiven update aller Eingänge des MCP nutzen könnte. (da Pollingintervall und nicht bei EVENT ein update)

Frage1)
Sehe ich das dann richtig,. dass ich das attrubut "separate_active-low" setzen muss und dann am nano einen IO nutze und den dann in FHEM als schalter / notify nutze um den GET des I2C_MCP23017 auszulösen?

Frage 2)
ich habe an einer Bank Relais (Standard Relaiskarte mit Oprokoplern) interessanterweise schalten die bei State OFF ein .. (weil die ja bei LOW anziehen)
Kann man den Level des Outputs invertieren ? >> kenne ich nur von den Eingängen

efmod NanoPortexpander I2C_MCP23017 0x20
attr NanoPortexpander IODev FIRMATA
attr NanoPortexpander InterruptOut separate_active-low
attr NanoPortexpander OutputPorts A0,A1,A2,A3,A4,A5,A6,A7
attr NanoPortexpander Pullup B0
attr NanoPortexpander event-on-change-reading .*
attr NanoPortexpander room FIRMATA

setstate NanoPortexpander Ok
setstate NanoPortexpander 2020-05-02 14:42:22 PortA0 on
setstate NanoPortexpander 2020-05-02 14:42:22 PortA1 on
setstate NanoPortexpander 2020-05-02 14:42:22 PortA2 on
setstate NanoPortexpander 2020-05-02 14:42:22 PortA3 on
setstate NanoPortexpander 2020-05-02 14:42:22 PortA4 on
setstate NanoPortexpander 2020-05-02 14:42:22 PortA5 on
setstate NanoPortexpander 2020-05-02 14:42:22 PortA6 on
setstate NanoPortexpander 2020-05-02 15:27:55 PortA7 on
setstate NanoPortexpander 2020-05-02 18:26:31 PortB0 off
setstate NanoPortexpander 2020-05-02 17:56:17 PortB1 off
setstate NanoPortexpander 2020-05-02 17:56:17 PortB2 off
setstate NanoPortexpander 2020-05-02 17:56:17 PortB3 off
setstate NanoPortexpander 2020-05-02 17:56:17 PortB4 off
setstate NanoPortexpander 2020-05-02 17:56:17 PortB5 off
setstate NanoPortexpander 2020-05-02 17:56:17 PortB6 off
setstate NanoPortexpander 2020-05-02 17:56:17 PortB7 off
setstate NanoPortexpander 2020-05-02 18:40:51 state Ok

jensb

zu 1) Mit dem MCP2301 kenne ich mich nicht aus.

zu 2) Es kommt darauf an, was du erreichen willst. Ziel sollte es sein, dass nach einem Stromausfall/Reset nichts aktiv wird, was ärger machen könnte und ggf. Alarme aktiv werden, die auf den Stromausfall/Reset hinweisen. Das sollte man möglichst mit Hardware machen. Und wenn das nicht geht halt mit der Firmware, die so nah wie möglich an der Hardware dran ist, bei dir also auf dem Arduino. Ich habe für diesen Anwendungsfall z.T. den Firmata-Init-Ablauf beim Reset geändert, damit die Outputs einen anderen Grundzustand bekommen (Firmata Sketch-Funktion setup). Die Invertierung kann man meist in FHEM durchführen (FRM_OUT: Attribut active_low).

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

R1F800

Zitat von: jensb am 03 Mai 2020, 10:48:18
. Ich habe für diesen Anwendungsfall z.T. den Firmata-Init-Ablauf beim Reset geändert, damit die Outputs einen anderen Grundzustand bekommen (Firmata Sketch-Funktion setup). Die Invertierung kann man meist in FHEM durchführen (FRM_OUT: Attribut active_low).

Hallo Jens,
vielleicht habe ich auch da ein Grundverständnisproblem ...
FRM_OUT hängt direkt am IO des nano > da ist das kein Problem bei der Deklatration der ACTIVE_LOW etc.
Es geht ausschließlich um den MCP23017 .. hier habe ich keine Möglichkeit die Schieberegister in ihrem Baselevel zu definieren ..

ODER muss ich zusätzlich ein FRM_OUT für das Schieberegister deklarieren obwohl es bereits untzer I2C_MCP23017 deklariert ist?

klausw

Hallo,

zu 1.
Ja so in etwa sollte das gehen.
Wenn auf beiden Bänken vom MCP Inputs genutzt werden kannst du auch connected_... verwenden.
Dann den INTx Ausgang (evtl. mit Pullup) auf einen als Input konfigurierten Port vom 328p legen.
Dann über notify die Daten holen.

zu 2.
Outputs lassen sich beim MCP nicht invertieren. Daher habe ich das auch nicht ins Modul mit aufgenommen.
Ich würde es über das Modul readingsProxy invertieren. Darüber bekommst du auch gleich für jeden Output ein Device.
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

R1F800

#43
Zitat von: klausw am 05 Mai 2020, 22:20:48
Hallo,

zu 1.
Ja so in etwa sollte das gehen.
Wenn auf beiden Bänken vom MCP Inputs genutzt werden kannst du auch connected_... verwenden.
Dann den INTx Ausgang (evtl. mit Pullup) auf einen als Input konfigurierten Port vom 328p legen.
Dann über notify die Daten holen.

wenn dich den INT-A und INT-B auf den Einganspin des nano Lege...  reicht dann ein interner PULLUP ?
Ich sehe zwar dass die Ports am MCP den Level ändern, nicht aber der INT an den PINs des nanos:
define NanoPortexpander I2C_MCP23017 0x20
setuuid NanoPortexpander 5ead6a7a-f33f-31ee-8efc-0d5df33d14cab621
attr NanoPortexpander IODev FIRMATA
attr NanoPortexpander InterruptOut separate_active-low
attr NanoPortexpander OutputPorts A0,A1,A2,A3,A4,A5,A6,A7
attr NanoPortexpander Pullup B0
attr NanoPortexpander event-on-change-reading .*
attr NanoPortexpander event-on-update-reading .*
attr NanoPortexpander room FIRMATA
attr NanoPortexpander verbose 5
define FRM_MCP_INTA FRM_IN 7
setuuid FRM_MCP_INTA 5eb50fc7-f33f-31ee-c294-0c5fd6fdd49af852
attr FRM_MCP_INTA IODev FIRMATA
attr FRM_MCP_INTA activeLow yes
attr FRM_MCP_INTA internal-pullup on
attr FRM_MCP_INTA room FIRMATA
attr FRM_MCP_INTA stateFormat reading
attr FRM_MCP_INTA verbose 5
define FRM_MCP_INTB FRM_IN 8
setuuid FRM_MCP_INTB 5eb50fff-f33f-31ee-c7e5-1355919ebbe30245
attr FRM_MCP_INTB IODev FIRMATA
attr FRM_MCP_INTB activeLow yes
attr FRM_MCP_INTB internal-pullup on
attr FRM_MCP_INTB room FIRMATA
attr FRM_MCP_INTB stateFormat reading
attr FRM_MCP_INTB verbose 5


R1F800

Hallo,

selbst mit einem PULL up des InteruptA / B am PIN7 /8 des 328p will FHEM hier den LOW Level nicht erkennen.
PULLUP = 3k8

Habe ich hier noch einen Denkfehler?