Hallo.
Ich habe mir ein Testbrett mit einen Arduino Nano(Lan) mit Firmata V2.06 und einem MCP23017 aufgebaut. Anbindung von Firmata an Fhem scheint zu funktionieren.
Ich nutze das Modul "I2C_MCP23017" und als IODev "FRM". Leider werden die Eingänge(ich benötige nur Eingänge) nicht eingelesen und es kommt ich die Fehlermeldung: too few Bytes received
Über die Suchfunktion habe ich einen Beitrag mit der selben Fehlermeldung gefunden. Es ging da um einen Temperatursensor.... ich glaube SHT..irgendwas..
Eine Lösung für mein Problem habe ich da leider nicht herausgelesen.
Hier ein "list" von den Geräten Firmata und MCP
Internals:
CONNECTS 2
DEF 3030 global
DRIVER_VERSION 0.64
DeviceName 3030
FD 4
I2C_ERROR Too few bytes received
NAME FIRMATA
NOTIFYDEV global
NR 22
NTFY_ORDER 50-FIRMATA
PORT 3030
STATE Initialized
TYPE FRM
firmware ConfigurableFirmataW5100I2C.ino
firmware_version V_2_06
i2c_pins 18,19
protocol_version V_2_06
READINGS:
2018-04-08 14:10:47 error I2C: Too few bytes received
2018-04-08 14:10:42 state Initialized
SERIAL:
SocketDevice:
BUF
DeviceName 3030
FD 10
NAME FIRMATA_192.168.178.251_49153
NR 67
PEER 192.168.178.251
PORT 49153
SNAME FIRMATA
SSL
STATE Connected
TEMPORARY 1
TYPE FRM
Attributes:
verbose 5
Internals:
DEF 20
I2C_Address 20
IODev FIRMATA
NAME MCP
NR 23
STATE Initialized
TYPE I2C_MCP23017
READINGS:
2018-03-22 01:28:05 PortA0 off
2018-03-22 01:28:05 PortA1 off
2018-03-22 01:28:05 PortA2 off
2018-03-22 01:28:05 PortA3 off
2018-03-22 01:28:05 PortA4 off
2018-03-22 01:28:05 PortA5 off
2018-03-22 01:28:05 PortA6 off
2018-03-22 01:28:05 PortA7 off
2018-03-22 01:28:05 PortB0 off
2018-03-22 01:28:05 PortB1 off
2018-03-22 01:28:05 PortB2 off
2018-03-22 01:28:05 PortB3 off
2018-03-22 01:28:05 PortB4 off
2018-03-22 01:28:05 PortB5 off
2018-03-22 01:28:05 PortB6 off
2018-03-22 01:28:05 PortB7 off
2018-03-31 13:41:54 state Ok
Attributes:
IODev FIRMATA
poll_interval 1
verbose 5
Hat jemand eine Idee wie ich den MCP zum laufen bekomme?
Dank und Gruß
besmart
Im FRM Device fehlt das Attribut i2c-config
Hallo.
Erst mal vielen Dank für deine Antwort.
Das Attribut i2c-config hatte ich schon ausprobiert. Leider keine Veränderung.....
Es sieht so aus, als ob die Kommunikation zwischen den Modulen "FRM" und "MCP23017" nicht funktioniert. Leider habe ich keine Ahnung wie ich das Problem eingrenzen kann...
Gruß
Dirk
es ist einen Weile her, das ich FRM genutzt habe.
Das Attribut "attr <frm-device> i2c-config 1" benötigst du auf alle Fälle.
Ohne geht es nicht.
Die I2C Pins sind korrekt angeschlossen?
Hast du ein Oszi zum messen?
Was ich gerade noch sehe...
Vorausgesetzt die Pins A0-A2 liegen auf Masse ist die Adresse des MCP23017 hexadezimal 20
du müsstest also 0x20 im DEF eintragen anstelle von 20
oder halt 32 (im Internal I2C_Address steht der Dezimalwert das wäre in beiden Fällen 32)
0x20 = 32
20 = 0x14
Moin,
ich stehe gerade vor dem gleichen Problem.
MCP23017 am Firmata Device (ardunino nano)
IOs am nano direkt funktionieren.
Ein LCD am I2C des nanos funktioniert auch.
NUR DER MCP23017 meckert rum. > Too few bytes received
Adresse sollte korrekt sein, Definition der Outputs sollten passen, SDA und SCL mit einem PullUp versehen ...
Hat jemand eine Idee warum hier ein TRANSMISSION ERROR kommt?
Ich glaube mich zu erinnern das für I2C ein Attribut in Firmata gesetzt werden muss
Zitat von: klausw am 05 Februar 2019, 18:40:04
Ich glaube mich zu erinnern das für I2C ein Attribut in Firmata gesetzt werden muss
Der I2C selber funktioniert ja. Das LCD hängt bereits am I2C und läuft. Somit sollte der Sketch ja i.O. sein.
Oder welches Attribut meinst Du ?
VG
Ingo
Zitat von: R1F800 am 06 Februar 2019, 10:20:27
Der I2C selber funktioniert ja. Das LCD hängt bereits am I2C und läuft. Somit sollte der Sketch ja i.O. sein.
Oder welches Attribut meinst Du ?
Handydisplay zu klein.. habe ich überlesen.
Das LCD am Firmata läuft demnach über FHEM und das Modul I2C_LCD?
Attribut: attr <frm-device> i2c-config 1
Aber wenn das LCD geht dann sollte es schon vorhanden sein.
Der MCP ist auf 0x20 konfiguriert?
Was bringt denn das setzen eines Ports um log (bei verbose5 in frm und i2c_mcp... Modul)?
Schau dazu bitte mal meinen Anhang aus dem vorangegangenen Post:
... Link klappt nicht >> Antwort #4
Das EventLog kann ich nachherposten, wenn ich wieder vor dem Gerät bin :-)
2019.02.06 18:07:10 3: NanoExpander: failure in message from FIRMATA
2019.02.06 18:07:10 3: Direction: i2cread I2Caddress: 0x20 Register: 0x12 Data: undef received: 0x00
Zitat von: R1F800 am 06 Februar 2019, 18:09:41
2019.02.06 18:07:10 3: NanoExpander: failure in message from FIRMATA
2019.02.06 18:07:10 3: Direction: i2cread I2Caddress: 0x20 Register: 0x12 Data: undef received: 0x00
Da war ich etwas sparsam mit den logeinträgen :/
Vom Firmata müsste aber auch was kommen.
Die Meldung "Too few bytes received" wird vom FRM Device übertragen. Genauso wie das Internal FIRMATA_SENDSTAT, welches ich bei dir vermisse.
Mit der Meldung können eher die Firmata Spezis was anfangen. Ich vermute es bedeutet, das der MCP nix zurück liefert.
Das kann zum einen an Verbindungsproblemen oder auch an der falschen Adresse (ja ich wiederhole mich ;) ), oder einem Timing Problem liegen.
Läuft alles mit der gleichen Spannung?
Zum Timing habe ich was in der Commandref gefunden:
i2c-config <write-read-delay>, no default
Configure the Arduino for ic2 communication. Definig this attribute will enable I2C on all i2c_pins received by the capability-query issued during initialization of FRM.
As of Firmata 2.3 you can set a delay-time (in microseconds, max. 32767, default: 0) that will be inserted into I2C protocol when switching from write to read. This may be necessary because Firmata I2C write does not block on the FHEM side so consecutive I2C write/read operations get queued and will be executed on the Firmata device in a different time sequence. Use the maximum operation time required by the connected I2C devices (e.g. 30000 for the BMP180 with triple oversampling, see I2C device manufacturer documentation for details).
See: Firmata Protocol details about I2C
Scheinbar hat sich da was geändert seit ich das vor 5 Jahren mal getestet habe.
Hallo,
Nein, das Delay beim I2C config habe ich nicht verändert.
Auf dem nano ist auch nicht das firmata sondern das configurable firmata
Halt eben nur mut I2C digital IO und 1 Wire
Zitat von: klausw am 06 Februar 2019, 22:43:21
Da war ich etwas sparsam mit den logeinträgen :/
Läuft alles mit der gleichen Spannung? >> JA, alles auf einem Breadboard. Alles mit +5V
Zum Timing habe ich was in der Commandref gefunden:
i2c-config <write-read-delay>, no default
Configure the Arduino for ic2 communication. Definig this attribute will enable I2C on all i2c_pins received by the capability-query issued during initialization of FRM.
As of Firmata 2.3 you can set a delay-time (in microseconds, max. 32767, default: 0) that will be inserted into I2C protocol when switching from write to read. This may be necessary because Firmata I2C write does not block on the FHEM side so consecutive I2C write/read operations get queued and will be executed on the Firmata device in a different time sequence. Use the maximum operation time required by the connected I2C devices (e.g. 30000 for the BMP180 with triple oversampling, see I2C device manufacturer documentation for details).
See: Firmata Protocol details about I2C
Scheinbar hat sich da was geändert seit ich das vor 5 Jahren mal getestet habe.
Hier mal ein kompletter LOG auch zum Firmata, das ich jetzt auch auf Verbvose 5 gestellt hab.
2019.02.08 08:00:21 3: NanoExpander: failure in message from FIRMATA
2019.02.08 08:00:21 1: PERL WARNING: Argument "0 0" isn't numeric in sprintf at ./FHEM/52_I2C_MCP23017.pm line 416.
2019.02.08 08:00:21 3: Direction: i2cread I2Caddress: 0x20 Register: 0x12 Data: undef received: 0x00
2019.02.08 10:24:43 1: RMDIR: ./restoreDir/save/2019-01-02
2019.02.08 10:25:11 5: FIRMATA FRM:>f076200812000200f7
2019.02.08 10:25:11 5: FIRMATA FRM:<f0714900320043003a00200054006f006f002000660065007700200062007900740065007300200072006500630065006900760065006400f7f07720001200000000
2019.02.08 10:25:11 3: received String_data: I2C: Too few bytes received
2019.02.08 10:25:11 5: FIRMATA FRM:<00f7
2019.02.08 10:25:11 5: onI2CMessage address: '32', register: '18' data: [0,0]
2019.02.08 10:25:11 3: NanoExpander: failure in message from FIRMATA
2019.02.08 10:25:11 3: Direction: i2cread I2Caddress: 0x20 Register: 0x12 Data: undef received: 0x00
2019.02.08 10:28:12 5: FIRMATA FRM:>f076200812000200f7
2019.02.08 10:28:12 5: FIRMATA FRM:<f0714900320043003a00200054006f006f002000660065007700200062007900740065007300200072006500630065006900760065006400f7f0772000120000000000f7
2019.02.08 10:28:12 3: received String_data: I2C: Too few bytes received
2019.02.08 10:28:12 5: onI2CMessage address: '32', register: '18' data: [0,0]
2019.02.08 10:28:12 3: NanoExpander: failure in message from FIRMATA
2019.02.08 10:28:12 3: Direction: i2cread I2Caddress: 0x20 Register: 0x12 Data: undef received: 0x00
@R1F800
Das Log sagt meiner Ansicht nach folgendes:
Zitat2019.02.08 08:00:21 1: PERL WARNING: Argument "0 0" isn't numeric in sprintf at ./FHEM/52_I2C_MCP23017.pm line 416.
Mögliches Implementierungsproblem im Modul 52_I2C_MCP23017, könnte Folgefehler verursachen, sollte auch untersucht werden.
Zitat2019.02.08 10:25:11 5: FIRMATA FRM:>f076200812000200f7
F0=START_SYSEX, 76=I2C_REQUEST, 20=I2C-Adresse, 08=periodisches Lesen (benötigt FRM-Attribut sampling-interval), 12000200=Payload, F7=END_SYSEX
Die Antwort müsste nun mit >f077 beginnen (77=I2C_REPLY) und sich unaufgefordert periodisch wiederholen. Statt dessen kommt:
Zitat2019.02.08 10:25:11 5: FIRMATA FRM:<f0714900320043003a00200054006f006f002000660065007700200062007900740065007300200072006500630065006900760065006400f7f07720001200000000
und das ist identisch mit dem Text "I2C: Too few bytes received". Diese Meldung erzeugt das Firmata-Device, wenn es ein I2C-Read absetzt, aber keine oder nur eine unverständliche Antwort erhält.
Ich kenne mich mit dem MCP23017 nicht aus, aber es gibt ein paar I2C-Devices (z.B. MMA845X), die nur in einem besonderen I2C-Write/Read-Modus Daten ausspucken. Dieser Modus wird unter den Namen "repeated start" und "combined write/read" geführt und er müsste im Datenblatt beschrieben sein, wenn er gebraucht wird. Jedenfalls wäre dafür die Firmata Firmware zu patchen, denn es gibt dafür keine Einstellmöglichkeit über FRM. Habe das Datenblatt überflogen, konnte aber keinen Hinweis finden, es müsste also ein normales Write/Read reichen.
Das FRM-Attribut i2c-config sollte hier keinen großen Einfluss haben, da FRM ja nur einmal das Lesen startet, der Rest wird vom Firmata-Device autonom durchgeführt, es gibt also keine Mehrfachkommandos vom FHEM an Firmata.
Aber ist das FRM-Attribut "sampling-interval" gesetzt? Wenn nicht, wäre das eine mögliche Erklärung, warum keine Daten zurück kommen.
Im Datenblatt zeigt Abbildung 3.4 die I2C-Hardware-Addresskonfiguration. Die 3 Eingangspins A0-A2 sollten mit GND verbunden werden, damit man sicher 0x20 als Adresse bekommt.
Ansonsten kann ich mich nur der Vermutung von Klaus anschließen, dass der MCP23017 nichts zurück liefert.
Grüße,
Jens
Hallo,
ich habe jetzt einmal das sampling interval auf 30000 gesetzt, aber es tritt keine Besserung ein.
Wie gesagt am I2C des nano hängt ein LCD das prima funktioniert.
Normale FRM IN und OUT klappen auch super ... nur der MCP nicht.
Ich werde jetzt mal schauen, ob mein Steckbrett eine Macke hat ... ansonsten bin ich grad echt ratlos
Ein Test ohne das LCD-Display am Bus wäre ebenfalls einen Versuch wert, sofern noch nicht probiert.
Wenn du einen RPi mit zugängiger Pfostenleiste hast und das Bastelrisiko nicht scheust, könntest du den MCP direkt an den RPi hängen und überprüfen, ob es dann funktioniert. Falls sich dann immer noch nichts tut und du keinen Verdrahtungsfehler hat, ist der MCP wahrscheinlich defekt.
Eine weitere Option wäre es, einen "normalen" Arduino-Sketch ohne Firmata für den MCP einzuspielen, der z.B. eine LED anmacht, wenn sich am MCP was tut oder der einen Pin des Arduino an den MCP weitergibt und du das am MCP nachmisst.
Wenn du ein Digi-Scope zur Hand hast, könntest du dir auch den I2C-Bus ansehen und zumindest überprüfen, ob die Pegel normal aussehen.
Grüße,
Jens
Zitat von: jensb am 09 Februar 2019, 19:43:16
Mögliches Implementierungsproblem im Modul 52_I2C_MCP23017, könnte Folgefehler verursachen, sollte auch untersucht werden.
Werde ich mir anschauen.
Wenn 0x00 zurück geliefert wird gibt es aber meines Wissens keine Fehlermeldung.
Zitat von: jensb am 09 Februar 2019, 19:43:16
F0=START_SYSEX, 76=I2C_REQUEST, 20=I2C-Adresse, 08=periodisches Lesen (benötigt FRM-Attribut sampling-interval), 12000200=Payload, F7=END_SYSEX
Die Antwort müsste nun mit >f077 beginnen (77=I2C_REPLY) und sich unaufgefordert periodisch wiederholen. Statt dessen kommt:und das ist identisch mit dem Text "I2C: Too few bytes received". Diese Meldung erzeugt das Firmata-Device, wenn es ein I2C-Read absetzt, aber keine oder nur eine unverständliche Antwort erhält.
In den LCD Modulen wird meines Wissens ein PCF8574 verwendet.
Beim Studium der Datenblätter fiel mir auf, das dieser den gleichen Adressraum verwendet. Also per default auf 0x20 gestellt ist.
Das müsste aber auffallen, wenn LCD und MCP23017 die gleiche Adresse verwenden.
Zitat von: jensb am 09 Februar 2019, 19:43:16
Ich kenne mich mit dem MCP23017 nicht aus, aber es gibt ein paar I2C-Devices (z.B. MMA845X), die nur in einem besonderen I2C-Write/Read-Modus Daten ausspucken. Dieser Modus wird unter den Namen "repeated start" und "combined write/read" geführt und er müsste im Datenblatt beschrieben sein, wenn er gebraucht wird. Jedenfalls wäre dafür die Firmata Firmware zu patchen, denn es gibt dafür keine Einstellmöglichkeit über FRM. Habe das Datenblatt überflogen, konnte aber keinen Hinweis finden, es müsste also ein normales Write/Read reichen.
Es gibt keinen speziellen Modus. Die Register können einfach gelesen werden.
Klaus
Das LCD Display hat doch die StandardAdresse "0x27"
Der MCP23017 alle Adresspins auf GND > 0x20
Ich werde mal versuchen "NUR" den MCP am I2C zu testen. > der PI steht offen an meinem Schreibtisch und der MCP und Rest ist auf einem BREADBOARD zusammengesteckt.
An einem ESP8266 funktioniert der MCP generell wunderbar. Aber auch hier werde ich noch einmal einen gegentest machen, um einen möglichen Defekt des Bauteils auszuschließen.
Zitat von: R1F800 am 11 Februar 2019, 11:09:49
Das LCD Display hat doch die StandardAdresse "0x27"
Der MCP23017 alle Adresspins auf GND > 0x20
schade, wäre ein einfacher Fehler gewesen 8)
Zitat von: R1F800 am 11 Februar 2019, 11:09:49
Ich werde mal versuchen "NUR" den MCP am I2C zu testen. > der PI steht offen an meinem Schreibtisch und der MCP und Rest ist auf einem BREADBOARD zusammengesteckt.
Wenn alles offen ist könntest du den MCP direkt an den I2C des Pi anschließen
Zitat von: R1F800 am 11 Februar 2019, 11:09:49
An einem ESP8266 funktioniert der MCP generell wunderbar. Aber auch hier werde ich noch einmal einen gegentest machen, um einen möglichen Defekt des Bauteils auszuschließen.
läuft auch Firmata auf dem ESP?
Zitat von: klausw am 11 Februar 2019, 18:45:03
schade, wäre ein einfacher Fehler gewesen 8)
Ja, das stimmt... einfache Fehler wären zur Abwechslung mal schön.
Zitat von: klausw am 11 Februar 2019, 18:45:03
Wenn alles offen ist könntest du den MCP direkt an den I2C des Pi anschließen
Da könnte ich tun. Die Frage ist was wollen wir damit testen? Dass der MCP i.O. ist ?
Zitat von: klausw am 11 Februar 2019, 18:45:03
läuft auch Firmata auf dem ESP?
Nein, da läuft ESPeasy drauf.
Zitat von: R1F800 am 12 Februar 2019, 08:52:10
Da könnte ich tun. Die Frage ist was wollen wir damit testen? Dass der MCP i.O. ist ?
hmm macht wenig Sinn. Du hast ja schon geschaut ob er funktioniert.
Ich weiß nicht so recht wo wir da ansetzten können.
NAch der Analyse von Jens würde ich zusammenfassen:
- Botschaft wird korrekt von I2C_MCP23017 ans FRM Modul übertragen
- FRM Modul schickt die Botschaft raus.
- Es kommt Müll zurück
- I2C_MCP23017 Modul kommt eventuell nicht mit undefinierten Antworten zurecht
letzteres ist unschön aber nicht der Grund dafür das nix funktioniert.
Es scheint im Arduino schief zu gehen.
Versuche bitte über das Modul FRM_I2C Register aus dem MCP auszulesen.
Anstelle der Configurable Firmata kannst du auch den normalen Sketch nehmen. Da sollte I2C drin sein
Zitat von: R1F800 am 12 Februar 2019, 08:52:10
Nein, da läuft ESPeasy drauf.
Bedeutet, das es auch nicht über das Modul I2C_MCP23017.. geht?
Zitat von: jensb am 09 Februar 2019, 19:43:16
F0=START_SYSEX, 76=I2C_REQUEST, 20=I2C-Adresse, 08=periodisches Lesen (benötigt FRM-Attribut sampling-interval), 12000200=Payload, F7=END_SYSEX
Die Antwort müsste nun mit >f077 beginnen (77=I2C_REPLY) und sich unaufgefordert periodisch wiederholen. Statt dessen kommt:und das ist identisch mit dem Text "I2C: Too few bytes received". Diese Meldung erzeugt das Firmata-Device, wenn es ein I2C-Read absetzt, aber keine oder nur eine unverständliche Antwort erhält.
I2C_MCP23017 sendet:
$sendpackage{direction} = "i2cread";
$sendpackage{i2caddress} = 32; (0x20)
$sendpackage{reg} = 18; (0x12)
$sendpackage{nbyte} = 2;
12000200=Payload könnte zu 12 ... 02 (Register, Anzahl Bytes)
die Antwort
onI2CMessage address: '32', register: '18' data: [0,0]
vom Inhalt her auch. 0x12 und 0x13 müssten 0 sein wenn nix angeschlossen ist was den Pin Spannungsmäßig anhebt
Ja, den MCP23017 spreche ich beim ESPeasy nicht mit I2C_MCP23017 an.
Die Kommunikation regelt alleine das ESPeasy. Ich spreche die Ports GPA / GPB via Socket nud Namen an, die ich im ESPeasy definiert habe.
define 123.123.123.123 80 ESPBridge Name_des_GPA
Nun, wie kann ich mich da jetzt weiter dem möglichen Fehler im I2C_MCP23017 nähern?
Zitat von: R1F800 am 13 Februar 2019, 09:16:05
Nun, wie kann ich mich da jetzt weiter dem möglichen Fehler im I2C_MCP23017 nähern?
1. Ein paar Ports vom MCP auf VCC legen und schauen ob sich die Antwort im Log (verbose 5) ändert.
2.
define <name> FRM_I2C <i2c-address> <register> <bytes-to-read>sollte so aussehen denke ich:
define <name> FRM_I2C 0x20 0x12 0x02was kommt da zurück (auch im log)
3. Ist ConfigurableFirmata 2.06 überhaupt kompatibel zum aktuellen FHEM Modul? (laut FHEM Wiki ist 2.10.0 aktuell)
ich werde das die kommenden Tage mal ausprobieren....
1. Einen Schalter hatte ich schon an einen PIN der dann auf VCC gezogen wird. >> kein Effekt
2. werde ich testen
3. das kann ich nciht sagen ... könnte ich updaten ... und neu flashen... aber dann haben wir zwei mögliche Fehlerquellen....
eins nach dem anderen
Zitat von: klausw am 13 Februar 2019, 15:18:29
1. Ein paar Ports vom MCP auf VCC legen und schauen ob sich die Antwort im Log (verbose 5) ändert.
2. define <name> FRM_I2C <i2c-address> <register> <bytes-to-read>
sollte so aussehen denke ich: define <name> FRM_I2C 0x20 0x12 0x02
was kommt da zurück (auch im log)
3. Ist ConfigurableFirmata 2.06 überhaupt kompatibel zum aktuellen FHEM Modul? (laut FHEM Wiki ist 2.10.0 aktuell)
zu 1) keine Reaktion
zu 2)
2019-03-06 10:33:09 FRM FIRMATA error: I2C: Too few bytes received
2019-03-06 10:33:09 I2C_MCP23017 NanoExpander transmission error
2019-03-06 10:33:26 FRM_I2C FRMnachI2C values:
zu 3) hier habe ich jetzt 2_10 aktiv
Da sind sich die FHEM-Module ja einig. Vom MCP23017 kommen wohl keine Daten, das war das ursprüngliche Analyseergebnis.
Mach den Test mit dem FRM_I2C mit deinem LCD-Display und ohne MCP23017. Dann solltest du Daten bekommen, wenn der Arduino und Firmata in Ordnung sind.
Wenn selbst ohne I2C-Devices beim Abfragen nichts aus SDA und SCL-Pins heraus kommt, hat der Arduino (oder die Firmata-Firmware) ein Problem. Mit MCP23017 müsste die Pulsfolge länger werden. Nimm ein Digi-Scope und versuch das zu überprüfen. Schau dir auch die Pulsform an. Sie muss nicht genau rechteckig sein, aber Spikes sind z.B. ein Problem. Auch dafür kannst du das LCD-Display zum Vergleich heranziehen.
Grüße,
Jens
NUR das LCD dran, welches auch Daten selber empfängt und auch anzeigt.
define testI2C FRM_I2C 0x20 0x12 0x02
>>>
2019-03-08 08:25:17 FRM_I2C testI2C values:
2019-03-08 08:25:17 FRM_I2C testI2C values:
Zum Verständnis
(PI) <Ethernet> (nano mit ETH shield und configurableFirmata) <I2C> LCD / MCP23017
So sollte der Datenfluss eigentlich aussehen...
Hier fehlt "FRM FIRMATA error: I2C: Too few bytes received" - trotzdem wurde scheinbar nichts empfangen.
Kannst du mit Set über FRM_I2C irgendeine Änderung auf dem LCD erreichen, die man sehen kann? Dann wüsste man wenigstens, ob was ankommt. Ansonsten: DigiScope
Wenn du kein DigiScope hast, dann reduziere deinen Aufbau auf ein Minimum, also z.B. nur Arduino + LCD und spiele einen Mini-Arduino-Sketch ein, der was mit dem Display macht. Klappt das, dann das gleiche noch mal mit dem MCP23017. Geht auch das, dann mit beiden gleichzeitig.
Klappt auch das, kommt wieder Firmata ins Spiel und zunächst nur wieder das LCD. Mich würde dann interessieren, was mit verbose=5 ab TCP Connect bis zum 1. Lesezugriff über Firmata gesendet und empfangen wurde.
Grüße,
Jens
Zitat von: jensb am 08 März 2019, 21:32:07
Hier fehlt "FRM FIRMATA error: I2C: Too few bytes received" - trotzdem wurde scheinbar nichts empfangen.
Kannst du mit Set über FRM_I2C irgendeine Änderung auf dem LCD erreichen, die man sehen kann? Dann wüsste man wenigstens, ob was ankommt. Ansonsten: DigiScope
Wenn du kein DigiScope hast, dann reduziere deinen Aufbau auf ein Minimum, also z.B. nur Arduino + LCD und spiele einen Mini-Arduino-Sketch ein, der was mit dem Display macht. Klappt das, dann das gleiche noch mal mit dem MCP23017. Geht auch das, dann mit beiden gleichzeitig.
Klappt auch das, kommt wieder Firmata ins Spiel und zunächst nur wieder das LCD. Mich würde dann interessieren, was mit verbose=5 ab TCP Connect bis zum 1. Lesezugriff über Firmata gesendet und empfangen wurde.
Grüße,
Jens
Ja klar... das LCD ändert wie gwünscht die Daten auf dem Display. SO wie ich es schicke.
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?
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
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?
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
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.
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?
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.
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 :-) )
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.
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 ?
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
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
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?
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.
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
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?
SO ... läuft nun
Problem sitzt VOR dem Schirm
Ich habe elektrisch sauber verdrahtet, der INT A/B war sauber deklariert.
ABER
Die Reaktion auf die PORTs (Interrupts) als solches waren noch nicht definiert, dass diese dem INTA / B entsprechend HIGH / LOW melden sollen.
@R1F800
Moin. Ich habe zwar im Moment nicht vor irgend etwas in der Richtung zu machen, wäre es schön wenn du deine funktionierende komplett Lösung aufzeigen kannst :D
Ich hatte vor Jahren schon einmal versucht mit Firmata und I2C ein DS2482(?) anzusprechen,
aber da bin ich gescheitert.
Habe das dann mit den IO-Ports umgesetzt.
Gruß Gerd
Zitat von: Maista am 19 Mai 2020, 18:30:52
@R1F800
Moin. Ich habe zwar im Moment nicht vor irgend etwas in der Richtung zu machen, wäre es schön wenn du deine funktionierende komplett Lösung aufzeigen kannst :D
Ich hatte vor Jahren schon einmal versucht mit Firmata und I2C ein DS2482(?) anzusprechen,
aber da bin ich gescheitert.
Habe das dann mit den IO-Ports umgesetzt.
Gruß Gerd
Hallo,
ich hoffe nachfolgendes reicht als Antwort:
define FIRMATA FRM 3030 global
setuuid FIRMATA 5ead5167-f33f-31ee-874d-6f6e7d5e72a4d252
attr FIRMATA event-on-change-reading .*
attr FIRMATA i2c-config 1
define NanoPortexpander I2C_MCP23017 0x20
setuuid NanoPortexpander 5ead6a7a-f33f-31ee-8efc-0d5df33d14cab621
attr NanoPortexpander IODev FIRMATA
attr NanoPortexpander Interrupt B0,B1,B2,B3,B4,B5,B6,B7
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 .*
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 stateFormat reading
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 stateFormat reading
define MCP_GPA7 dummy
setuuid MCP_GPA7 5eb515e5-f33f-31ee-43ba-be29ef22cc3dc7c1
attr MCP_GPA7 room FIRMATA
attr MCP_GPA7 webCmd on:off
Moin Zusammen.
Ich doktere jetzt wieder / immer noch an dem automatischen Pull meiner IOs am MCP23017 via Firmata rum.
Leider klappt ein Aktualisieren der Port Zustände mit dem INTERRUPT derzeit nicht. Vielleicht mache ich ja noch einen Fehler?
hier mal meine Definitionen:
define FIRMATA FRM 3030 global
setuuid FIRMATA 5d04bada-f33f-d199-882c-cc1d46254275b461
attr FIRMATA event-on-change-reading .*
attr FIRMATA i2c-config 1
attr FIRMATA model nano
attr FIRMATA room Firmata
attr FIRMATA sampling-interval 12000
attr FIRMATA verbose 0
define FRM_MCP_INTA FRM_IN 5
attr FRM_MCP_INTA IODev FIRMATA
attr FRM_MCP_INTA activeLow yes
attr FRM_MCP_INTA room FIRMATA
attr FRM_MCP_INTA userReadings test {fhem "get NanoPortexpander"}
define FRM_MCP_INTB FRM_IN 6
attr FRM_MCP_INTB IODev FIRMATA
attr FRM_MCP_INTB activeLow yes
attr FRM_MCP_INTB room FIRMATA
attr FRM_MCP_INTB userReadings test {fhem "get NanoPortexpander"}
define NanoPortexpander I2C_MCP23017 0x20
attr NanoPortexpander IODev FIRMATA
attr NanoPortexpander Interrupt B0,B1,B2,B3,B4,B5,B6,B7
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
EDIT KJlammern um den CODE "get NanoPortexpander" entfernt. Jetzt klappt das Notify
Nun habe ich wohl dann noch ein Problem mit meinem Notify :
define n_MCP_GPB0on notify { fhem "NanoPortexpander PortB0:on set NanoPortexpander PortA7:off"}
define n_MCP_GPB0off notify {fhem "NanoPortexpander PortB0:off set NanoPortexpander PortA0:on"}
Vielleicht hat da noch jemand eine Idee ... es soll wenn das ON Signal auf PORT B kommt der Ausgang auf PORT A geschaltet werden ....
Zitat von: R1F800 am 26 November 2020, 08:49:25
define n_MCP_GPB0on notify { fhem "NanoPortexpander PortB0:on set NanoPortexpander PortA7:off"}
define n_MCP_GPB0off notify {fhem "NanoPortexpander PortB0:off set NanoPortexpander PortA0:on"}
define n_MCP_GPB0on notify NanoPortexpander:PortB0:on set NanoPortexpander PortA7 off
define n_MCP_GPB0off notify NanoPortexpander:PortB0:off set NanoPortexpander PortA0 on
oder alles in eines packen , dann darfst auch wieder mit Perl arbeiten :)
define n_MCP_GPB0 notify NanoPortexpander:PortB0:o(n|ff) { if $EVTPART1 eq ....
wieso werden das Device und der Port mit : von einander getrennt
Zitatdefine n_MCP_GPB0 notify NanoPortexpander:PortB0:o(n|ff) { if $EVTPART1 eq ....
den roten Block verstehe ich nicht ... Tippfehler ? oder versteh ich es einfach so nciht ?
ja warum werden die mit Doppelpumkt getrennt ? Vermutlich weil Rudi das so vor vielen Jahren programmiert hat.
Tipp : Eventmonitor aufmachen, Event markieren und den Wizzard starten, dann hast den auch drin
Was den roten Block betrift : in der Tat da war ich etwas zu schnell :
define n_MCP_GPB0 notify NanoPortexpander:PortB0:.o(n|ff) {
wäre richtig, man beachte den Punkt ! Natürlich kann man das auch verkürzen zu :
define n_MCP_GPB0 notify NanoPortexpander:PortB0.* {
damit hast ein notify das auf alles reagiert was PortB0 jemals ausspucken kann, findet man (leider) sehr oft hier im Forum/Wiki.
Durch diverse Ereignisse hier in dem letzten 9 Monaten bin ich allerdings sehr sensibel geworden gegenüber RegEx die auf zu viel matchen, daher befolge ich gerade bei Beispielen nun immer die Regel "nur zulassen was wirklich unbedingt gebraucht wird"
In deinem Fall PortB0:.o , denn bis zu diesem kleinen o sind die Events on & off identisch. Nun kommt aber noch n oder ff um das Wort zu vervollständigen und das ist in RegEx Sprache nunmal (n|ff)
Verständliche Beschreibung DANKE!
Von solchen Beschreibungen hätte ich gerne mehr ;) Meistens kommt imme rnur eine Lösung und keine Hintergründe .. aber die Hintergründe lassen zusammenhänge erkennen ;)
Gibt es einen GLossar / Handbuch zu RegEx? also ich meine nicht die Befelsbeschreibungen sondern die Grundlagen dazu?
Mir gefällt das Eindeutige Statemant eindeutig besser, ich probiere das gleich aus ...
wenn ich das dann richtig verstehe
Zitat{ if $EVTPART1 eq ....
[/color]
sollte das so gehen ?
{ if $EVTPART1 eq on set NanoPortexpander PortA7 off , if $EVTPART1 eq off set NanoPortexpander PortA7 on }
nun zu RegEx gibt es im Netz zig tausend Anleitungen , IMHO gut zum testen und lernen und immer wieder hier empfojlen : https://regex101.com/
if $EVTPART1 eq on geht gar nicht , wenn dann if ($EVTPART1 eq 'on') und der ausführbate Teil in geschweifte Klammern :
if ($EVTPART1 eq 'on') { fhem('set NanoPortexpander PortA7 off') }
also wieder zurück zu FHEM da set NanoPortexpander PortA7 on kein Perl Befehl ist sondern FHEM
define n_MCP_GPB0 notify NanoPortexpander:PortB0:.o(n|ff) {
if ($EVTPART1 eq 'off') { fhem('set NanoPortexpander PortA7 on'); }
if ($EVTPART1 eq 'on') { fhem('set NanoPortexpander PortA7 off'); }
}
Aber da haben wir wieder so ein unschönes oft genanntes Beispiel : ich mag diese Perl->FHEM->Perl Wechsel nicht :( , ich bin da Fan von CommandSet
und da wir nun ein Befehle haben das if dahinter statt davor um Klammern zu sparen
wäre es mein notify:
define n_MCP_GPB0 notify NanoPortexpander:PortB0:.o(n|ff) {
CommandSet(undef, 'NanoPortexpander PortA7 on') if ($EVTPART1 eq 'off');
CommandSet(undef, 'NanoPortexpander PortA7 off') if ($EVTPART1 eq 'on');
}
Zitat von: Wzut am 27 November 2020, 09:12:02
nun zu RegEx gibt es im Netz zig tausend Anleitungen , IMHO gut zum testen und lernen und immer wieder hier empfojlen : https://regex101.com/
if $EVTPART1 eq on geht gar nicht , wenn dann if ($EVTPART1 eq 'on') und der ausführbate Teil in geschweifte Klammern :
if ($EVTPART1 eq 'on') { fhem('set NanoPortexpander PortA7 off') }
also wieder zurück zu FHEM da set NanoPortexpander PortA7 on kein Perl Befehl ist sondern FHEM
define n_MCP_GPB0 notify NanoPortexpander:PortB0:.o(n|ff) {
if ($EVTPART1 eq 'off') { fhem('set NanoPortexpander PortA7 on'); }
if ($EVTPART1 eq 'on') { fhem('set NanoPortexpander PortA7 off'); }
}
Aber da haben wir wieder so ein unschönes oft genanntes Beispiel : ich mag diese Perl->FHEM->Perl Wechsel nicht :( , ich bin da Fan von CommandSet
und da wir nun ein Befehle haben das if dahinter statt davor um Klammern zu sparen
wäre es mein notify:
define n_MCP_GPB0 notify NanoPortexpander:PortB0:.o(n|ff) {
CommandSet(undef, 'NanoPortexpander PortA7 on') if ($EVTPART1 eq 'off');
CommandSet(undef, 'NanoPortexpander PortA7 off') if ($EVTPART1 eq 'on');
}
beide EVTPART haben die laufende Nr. 1? nicht 0 und 1 ?
Die Anführungszeichen sind Literale ' oder Anführungszeichen " ?
Ich habe das notify mal so einbeuat, aber im EVENTmanager sehe ich keinerlei aktivität des notifies
Tipp : bitte bei Gelegenheit etwas mehr Perl Grundlagen anlesen.
Innerhalb deines notifiys gibt es $EVENT, $EVTPART0 und $EVTPART1
$EVENT = PortB0: on oder PortB0: off
$EVTPART0 = PortB0:
$EVTPART1 = on oder off
In meinem Beispiel kannst du sowohl ' verwenden als auch " , richtiger ist in diesem Fall aber ' (siehe wieder Perl Grundlagen)
was willst du vom notify sehen ? Wenn es einen Trigger bekommen hat steht in der Webansicht Datum und Uhrzeit
siehst den keine Events deines NanoPortexpanders im Event Monitor ?
edit ich sehe da gerade bei dir
attr NanoPortexpander event-on-change-reading .*
attr NanoPortexpander event-on-update-reading .*
wirf bitte mal beide raus und verwende solche Kombis nicht
Doch klar sehe ich bei meinem Portexpander die Evenmts:
2020-11-27 13:49:26 I2C_MCP23017 NanoPortexpander PortB0: on
2020-11-27 13:49:26 I2C_MCP23017 NanoPortexpander Ok
2020-11-27 13:49:26 FRM_IN FRM_MCP_INTB reading: off
2020-11-27 13:49:26 I2C_MCP23017 NanoPortexpander Ok
2020-11-27 13:49:30 FRM_IN FRM_MCP_INTB reading: on
2020-11-27 13:49:30 I2C_MCP23017 NanoPortexpander PortB0: off
2020-11-27 13:49:30 I2C_MCP23017 NanoPortexpander Ok
2020-11-27 13:49:30 FRM_IN FRM_MCP_INTB reading: off
2020-11-27 13:49:30 I2C_MCP23017 NanoPortexpander Ok
aber das SET für den PORTA7 kommt nicht an. Soll heißen es tut sich nichts
Zitat von: Wzut am 27 November 2020, 13:26:40
$EVENT = PortB0: on oder PortB0: off
$EVTPART0 = PortB0:
$EVTPART1 = on oder off
dann ist Part0 das Device und Part1 der Zustand des devices?
und das FHEM Log hat auch keinen Fehlereintrag ? Zeig bitte mal ein list von dem notify
(kein DEF und kein RAW bitte wie gestern , sondern ein echtes list)
Hier das List vom notify:
nternals:
DEF define n_MCP_GPB0 notify NanoPortexpander:PortB0:.o(n|ff) {
CommandSet(undef, 'NanoPortexpander PortA7 on') if ($EVTPART1 eq 'off');
CommandSet(undef, 'NanoPortexpander PortA7 off') if ($EVTPART1 eq 'on');
}
FUUID 5fc0c001-f33f-31ee-62a1-c3bf2c35c9dadd58
NAME n_MCP_GPB0
NR 21
NTFY_ORDER 50-n_MCP_GPB0
REGEXP define
STATE active
TYPE notify
READINGS:
2020-11-27 16:02:58 state active
Attributes:
addStateEvent 1
room FIRMATA
verbose 5
und hier mal eins von meinem DOIF, das funktioniert. Nicht falsch verstehen, ich möchte das gerne mit einem notify machen und das Thema verstehen .. nur weil das funktioniert hör ich bei dem notify noch cniht auf :-D
Internals:
DEF ([NanoPortexpander:PortB0] eq "on") (set NanoPortexpander PortA7 off)
DOELSEIF
([NanoPortexpander:PortB0] eq "off") (set NanoPortexpander PortA7 on)
FUUID 5fc0fc63-f33f-31ee-120e-4fb80bbc7cbd653d
MODEL FHEM
NAME FRM_DOIF_GPB0
NOTIFYDEV global,NanoPortexpander
NR 22
NTFY_ORDER 50-FRM_DOIF_GPB0
STATE cmd_2
TYPE DOIF
VERSION 23235 2020-11-25 22:42:28
READINGS:
2020-11-27 16:03:20 Device NanoPortexpander
2020-11-27 16:03:20 cmd 2
2020-11-27 16:03:20 cmd_event NanoPortexpander
2020-11-27 16:03:20 cmd_nr 2
2020-11-27 16:03:20 e_NanoPortexpander_PortB0 off
2020-11-27 14:30:08 mode enabled
2020-11-27 16:03:20 state cmd_2
Regex:
accu:
cond:
NanoPortexpander:
0:
PortB0 ^NanoPortexpander$:^PortB0:
1:
PortB0 ^NanoPortexpander$:^PortB0:
attr:
cmdState:
wait:
waitdel:
condition:
0 ::ReadingValDoIf($hash,'NanoPortexpander','PortB0') eq "on"
1 ::ReadingValDoIf($hash,'NanoPortexpander','PortB0') eq "off"
do:
0:
0 set NanoPortexpander PortA7 off
1:
0 set NanoPortexpander PortA7 on
2:
helper:
DEVFILTER ^global$|^NanoPortexpander$
NOTIFYDEV global|NanoPortexpander
event PortB0: off
globalinit 1
last_timer 0
sleeptimer -1
timerdev NanoPortexpander
timerevent PortB0: off
triggerDev NanoPortexpander
timerevents:
PortB0: off
timereventsState:
PortB0: off
triggerEvents:
PortB0: off
triggerEventsState:
PortB0: off
internals:
perlblock:
readings:
all NanoPortexpander:PortB0
trigger:
uiState:
uiTable:
Attributes:
do always
room FIRMATA
Zitat von: R1F800 am 28 November 2020, 12:50:53
Nicht falsch verstehen
ne,ne ist schon klar, alles was sofort funktioniert ist eh langweilig :) An deinem list sieht man das das noitify noch nie getriggert wurde, also kann man sich Fehlersuche intern erst einmal ersparen und sich auf die RegEx des Define konzentieren.
Ändere die doch mal ab auf define n_MCP_GPB0 notify NanoPortexpander:PortB0.*
es wird dann unnötig oft getriggert, aber das erseinmal egal da ja intern sehr genau unterschieden wird.
Du kannst auch am notify selbst noch verbose 5 setzen dann erzeugt es selbst einen Log Entrag des Aufrufs.
Moin...
was soll ich sagen, manchmal liegt die ??? Lösung derart Nahe das man 20 Mal drüberschaut... :-[
Das Notify funktioniert nun sowohl mit .* als auch mit .o(n/ff) .... Erst einmal gut !! Jetzt kommts, man lenke sein Augenmerk mal von den was einem offendichtlich erscheint auf das unglaubwürdig fehlerhafte (ich hatte ja meine lists gepostet) :
Internals:
DEF define n_MCP_GPB0 notify NanoPortexpander:PortB0:.o(n|ff) {
CommandSet(undef, 'NanoPortexpander PortA7 on') if ($EVTPART1 eq 'off');
CommandSet(undef, 'NanoPortexpander PortA7 off') if ($EVTPART1 eq 'on');
}
der Term gehört ja nicht in die Definition ... sondern Beschreibt ja eher das Device beim Anlegen ... Kopierfehler.
Trotzdem
Besten Dank !!
Jetz die allumfassend pghilosophische Frage... Wieso DOIF oder wieso NOTIFY ... beide machen hier ja das Gleiche ...
Gegenfrage : warum Pepsi statt Coca Cola ? Kommen beide aus Amiland und sind schwarz mit Kohlensäure ....
Das ich das in deinem list übersehen habe ärgert mich jetzt richtig :(
Na .. es lag zu nah :-D
Noch einmal eine Nachfrage.
Ich habe jetzt ein Relaisboard 8fach am MCP23017 PORTA
als erstes sind schon einmal ALLE Relais beim Startup "an". OK das könnte man ja mit OnStartUp beheben ...
Wenn ich jetzt aber ein Relais ausschalte .. sagen wir A7 und dann im Nachgang A6 .. geht A7 wieder in den Initialwert "an"
Mir scheint als wäre das Logiklebvel genau invertiert ... Wie bekomme ich das "umgedreht" ?
EDIT: kann man jaeigentlich mit leben.
viel irritierender ist die Tatsache, dass ich die Ports gegenseitig scheinbar beineinflussen .. A7 an andere Port A3 z.B. geht aus .. oder umgekehrt ..