Full rewrite, many enh., no more crashing, see change log

PizzaProgram commented 3 years ago

Please apply. It's there since 2021-03

willhey commented 3 years ago

I downloaded from PizzaProgram/mcp23017chip Replaced the module on a Raspberry Pi Set the bus to 1 (new control on dialog) & deployed There are no debug errors, but it does not respond to input changes Always shows "unknown yet" Does not appear to be backward compatible Not sure where to start debugging

PizzaProgram commented 3 years ago

Thanks for giving it a try! I've never tried the INPUT function, only the output. Let me see if I can create a test environment to debug it myself. Until than, can you connect to your RPi with a terminal and can you check the LOG ? $ node-red-log

willhey commented 3 years ago

Hi, Nothing relevant in the log

PizzaProgram commented 3 years ago

OK, understand. How about the "side log" ? Do you see something there? Like: kép

willhey commented 3 years ago

Nothing in side debug I replaced all the //console for console in .js file Then changed the following to include underscore (isInput, bitNum, pullUp, Invert, callerNode) The terminal now has

6 Sep 14:33:36 - [info] Starting flows chip inic ok. chip inic ok. setBit started... bitNum=15 isInput=true pullUp=true invert=false caller:7864a6a4.cd5f08 opening bus... OK. Closing bus. ...state update _obj:[object Object] _onOffState:false _localErr:falsethis.globalState=0 this=[object Object] setBit started... bitNum=14 isInput=true pullUp=true invert=false caller:22241929.3f9b76 opening bus... OK. Closing bus. ...state update _obj:[object Object] _onOffState:false _localErr:falsethis.globalState=0 this=[object Object] setBit started... bitNum=14 isInput=true pullUp=true invert=false caller:3c0dadf.cc2b652 opening bus...

PizzaProgram commented 3 years ago

OFF: I will need more time to:

look through and remember the whole code I wrote 8 month ago
solder the A0 A1 .. pins at a secondary MCP chip, so I can attach it to the bus next to the other.

Thanks for your patient.

Marooned-MB commented 3 years ago

While you are having look on the input nodes, maybe it would be a quick addition to add them an input so they can be forced to read the state from the chip?

I'm using this chip to read all my windows/doors open state so 100% as input data. The problem is that after some time™ it stops refreshing the data and there is no way to invoke "refresh" command, so re-read all inputs and publish its state (even if they haven't changed).

Even better would be to introduce new node using internal interrupts - I have Python script which is setting interrupt and this cancels all the unnecessary polling which is done by those input nodes and also it's better to catch fast input changes that could be missed by polling but that's separate idea.

PizzaProgram commented 3 years ago

OFF:

@Marooned-MB The input is FORCED to read it every milliseconds, how you have set.

I don't know, why my new version isn't working, theoretically it should rear the state of all pins many times a second as it had before. Except it can not freeze / crash any more, because it's protected against that in may ways. (Like: Can not start read or write operation while an other process is already in the middle of it)

Actually I'm going to drop this whole i2c standard, because:

An Arduino Nano (remake) board costs the same as this panel, having more inputs and an easy plug&play way to attach.
i2c has no default shielding of the cables, (USB has!)
it's very hard to activate the i2c inside the kernel, also it can change the bus number every time you plug in a new USB/i2c adapter
it's slow (compared to USB min. 1 Mbaud+ )
you can not cable it more than ca 50cm (USB can be 450cm + you can extend it with hubs and extenders cheaply)

PizzaProgram commented 3 years ago

@Marooned-MB

The interrupt on this board is "functioning" the following way:

you can READ it, but it takes the same time as reading the whole bank (8+ pins). So it makes no sense.
it can not SEND signals to you through the i2c bus
So you need a different hardware to connect phisicaly the INT-A and INT-B pins to, which device (like a Raspberry Pi) needs to check continouosly if the pin has any changes ? So you are where you have started: .. you need a quick device to continuously read some values (either Int-pins or the whole bank) non-stop.

Marooned-MB commented 3 years ago

@PizzaProgram - in my Python script it looks like this:

#setup RPi
GPIO.setmode(GPIO.BCM)

# GPIO 23 set up as input. It is pulled up to stop false signals
GPIO.setup(23, GPIO.IN, pull_up_down=GPIO.PUD_UP)

GPIO.add_event_detect(23, GPIO.FALLING, callback=mcpInterrupt)

so reading of MCP chip is done inside mcpInterrupt function and only when some input is changed (causing interrupt to fire up) so no polling every xx miliseconds. Sounds more efficient to me.

And here is my setup if anyone would find it helpful:

#setup MCP23017
bus = smbus.SMBus(1)
#REGISTER 1-1: IODIR – I/O DIRECTION REGISTER (ADDR 0x00/01) -> 0: output; 1: input
bus.write_byte_data(mcpAddress, 0x00, 0xff) #A0-A7 as input
bus.write_byte_data(mcpAddress, 0x01, 0xff) #B0-B7 as input
#REGISTER 1-2: IPOL – INPUT POLARITY PORT REGISTER (ADDR 0x02/03) -> invert 0: normal; 1: inverted
bus.write_byte_data(mcpAddress, 0x02, 0x00) #A0-A7 active==1
bus.write_byte_data(mcpAddress, 0x03, 0x00) #B0-B7 active==1
#REGISTER 1-3: GPINTEN – INTERRUPT-ON-CHANGE PINS (ADDR 0x04/05) -> interrupt 0: disabled; 1: enabled
bus.write_byte_data(mcpAddress, 0x04, 0xff) #A0-A7 causes INT
bus.write_byte_data(mcpAddress, 0x05, 0xff) #B0-B7 causes INT
#REGISTER 1-5: INTCON – INTERRUPT-ON-CHANGE CONTROL REGISTER (ADDR 0x08/09) -> compare with 0: previous; 1: default
#REGISTER 1-6: IOCON – I/O EXPANDER CONFIGURATION REGISTER (ADDR 0x0a/0b) -> 7: bank; 6: mirror; 5: seqop; 4: disslw; 3: haen; 2: odr; 1: intpol; 0: n/c
IOCON = bus.read_byte_data(mcpAddress, 0x0a)
IOCON |= 0b01100100 #mirror | byte mode | odr (open drain interrupt)
bus.write_byte_data(mcpAddress, 0x0a, IOCON)
#REGISTER 1-7: GPPU – GPIO PULL-UP RESISTOR REGISTER (ADDR 0x0c/0d) -> pull-up 0: disabled; 1: enabled
bus.write_byte_data(mcpAddress, 0x0c, 0xff) #A0-A7 pull-up
bus.write_byte_data(mcpAddress, 0x0d, 0xff) #B0-B7 pull-up
#REGISTER 1-8: INTF – INTERRUPT FLAG REGISTER (ADDR 0x0e/0f) -> which pin caused INT (read-only)
#REGISTER 1-9: INTCAP – INTERRUPT CAPTURED VALUE FOR PORT REGISTER (ADDR 0x10/11) -> snapshot of GPIO at the time of INT (cleared by reading it or GPIO)
#REGISTER 1-10: GPIO – GENERAL PURPOSE I/O PORT REGISTER (ADDR 0x12/13) -> GPIO

Anyway, yeah, I went too offtopic probably for this thread, sorry. Cheers.

PizzaProgram commented 3 years ago

@Marooned-MB OK, I understand now your request:

you need an "input" node-point to the MPC-input node, so you can force-read the values.

I've already added during the last week to the component this, but it seem there is a big problem with e i2c module. Opened a ticked but no answer yet: https://github.com/fivdi/i2c-bus/issues/95

PizzaProgram commented 3 years ago

@willhey please add me to this project as co-worker.

willhey commented 3 years ago

Why do you want to be added as a co-worker ?

geoffreydemaagd commented 3 years ago

Why do you want to be added as a co-worker ? It can't be merged if the permissions are not granted. I think you have to add him as a collaborator

willhey / mcp23017chip

Full rewrite, many enh., no more crashing, see change log #11