How to enhance the needed pins for sensors? Can the PCF8574 module be useful?

[sjorsBe]

Hi all,

there is some thinking going on how to connect extra sensor device to the module without consuming a number of pins. On the other hand Michael did already a superb job by providing an I2c bus for the module. In the arduino world it is common practice to expand the number od controllabe pins with e.g an PCF8574 module. The PCF8574 is a silicon CMOS circuit. It provides general purpose remote I/O expansion for most microcontroller families via the two-line bidirectional bus (I2C). The device consists of an 8-bit quasi-bidirectional port and an I2C-bus interface. Especially in the mqtt version the adress-configuration of each additional pin could potentially be done in dataexchange between broker and client. And therefore offer space for using more sensors like DTH11 or DTH22’s

Is there room for support of an PCF8574? or look alike module? It would make the use of extra pins configurable…

kr

sjors https://www.instructables.com/PCF8574-GPIO-Extender-With-Arduino-and-NodeMCU/

[nielsonm236]

I looked at the PCF8574 specs and this should be simple at the backend driver. But here are the issues:

1) The I2C "bus" that I implemented is a "bit-bang" method using two of the IO pins. So, not very fast but fully functional. If someone wants this to be a fast interface ... well, it won't be fast.

2) The I2C bus is currently only available when using the "upgradeable" code. That requires attachment of the 1024Mbit external EEPROM. The reason this happened is due to the very small amount of code space remaining in the non-upgradeable versions. The upgradeable versions store all their webpages in the external EEPROM instead of in the Flash making several KB of additional Flash space available for code. If attaching an external EEPROM is not acceptable I can look into whether the I2C driver will fit in the existing non-upgradeable versions. It might.

3) The user interface to the PCF8574 might be problematic. If we need a Browser GUI it will be a tight fit due to the limited Flash space in the non-upgradeable code. It will easily fit in the upgradeable code. If we ONLY need this to work with MQTT or with REST commands (no Browser GUI) then the code space for the user interface is much smaller and might fit. Now having said that my friends talented in Javascript might have a good (small) solution ... or with a little time I can figure it out.

In terms of "when" I must admit I am having difficulty resolving a current issue with needed changes in the size of the uip_buffer. The problems suggest I have an underlying bug causing interaction of MQTT and Browser TCP/IP connections or buffer over-run, so it might still be a few weeks before I get back to new enhancements.

Feedback welcome.

Mike

[sjorsBe]

Hi mike, Thanks vor your answer. Reading it gave me an idea. I struggled a bit with the eeprom solution because it would add extra loose parts to the module. And loose parts will allways fail. :) But reading your answer gave me an idea to design a small piggy bag pcb to be placed on top of the 20 pins to include the eeprom and a pcf8575 to add 16 pins :) and a 4 pin connector for an extra extension of the I2C. the pcb would be nicely small and firmly attached go the module itself. on top of the piggybag 14 of the original pins could be used and another 16 for sensors and whatever other stuff. The eeprom would give you the space to keep on developping :) The module would stay nice and small, updates of the firmware would be easy and extra pins for sensors would be nice. The parts for are easily available, and quite cheap ( the eprom or the connectors would be the most expensive, i think :) ) The next few week i havent got the time for it, work and my wife wants me to deliver the fully automated christmas village ( yes, thats where all the effort is for ) but after that the pcb is easily done. ( people who are willing go help: im using eagle pcb design ) Is this an idea?

[nielsonm236]

Yes - a good idea. I've developed two boards that allow me to experiment with expanded functionality and to display pin states. This was done in part to enable code development test, but also gives me a platform for my own home automation. And, of course, just fun for a hobby. Another developer also created his own board to add the off-board EEPROM and connect relays via screw terminals. The off-board EEPROM is especially useful if the boards are located in hard-to-reach areas - you can reprogram over ethernet instead of attaching a cable.

FYI I used KiCAD for schematic and layout, then used PCBWay for PCB manufacturing. Very inexpensive.

[sjorsBe]

Ill design the pcb including pcf and eeprom, to be used by everyone, including gerber files, will you program the pcf solution using the extra memory in eeprom? I work with jclpcb, cheap and fast!

Sjors

[nielsonm236]

Yes - I'll work on the PCF idea when I can get the current issues off the plate. I will probably have to count on you to test it. At first only via REST commands, then MQTT, and we will decide if we need more GUI support. Hope I haven't agreed to something with some unseen major issue. :-)

[sjorsBe]

I can design for an PCF8574 (8 i/o) or an PCF8575 (16 i/o) what do you prefer?

kr Sjors

[nielsonm236]

Either is fine with me. But anything worth doing is worth doing twice as loud, eh? Probably go with 16 i/o. Is the 16 i/o a lot more expensive? If you are designing a board you might be able to put both footprints on it with the intention that you only put one of the devices on.

[sjorsBe]

Hi Michael,

a few questions regarding the PCB

1. I decided to first design a combined 24LC1025 and PCF8574P board. This should be that small that it would fit from the 20 pins header to the start of the RJ45 connector. its 2.8cm x 3.0 cm - not really big but very handy.

2. It had its own AMS 1117 3.3 power convertor with a common ground. ( no diode but C buffers 10uF and 22uF )

3. The SDA and SCK have their own 10 pullup resistor to support the I2C

4. It has an 10 pin connector on the side: Power +, pins E1-E8 and GND.

5. The address of the EEprom is fixed ( all 0 ) and so is the Write protect and CS ( A2) ( +3.3v)

6. The PCF8574 is fixed A0-A2 to 0. (address 0x40/41 for PCF8574 or 0x70/71 for PCF8574P)

7. The pins on the original 20 pins will be extended except for pin 15 and 14

Am i missing anything? IThis all seems to fit, as long as someone dont want to pus 1Amp through it :)

Please let me know

kr

Sjors

Questions are:

1. E1-E8 should they be +5V or +3.3 v? when active ?
2. Currently the PCF8574 will receive 3.3v ( which i do have to test ....) ?
3. The int will not be used. ok?

[nielsonm236]

I'm having a little trouble visualizing some of what you've done. You might be able to attach a screen shot of the schematic and/or layout (or email them to me). But here are my thoughts with some guessing: Item 3: The SDA and SCK pull-ups should go to 3.3V. Item 4: E1-E8 are the IO pins on the PCF8574? Are you going to also support the 8575? Item 5: The A0 and A1 pins should be to ground. The A2 pin should be to 3.3V. The WP pin should be to ground. Item 7: I'd suggest a couple of things: a) Use a jumper to either pass pin 14 and 15 through when an EEPROM is not installed, or to direct the signals to the EEPROM when it is installed. I'd also suggest putting a single footprint for a DS18B20 temperature sensor, and a jumper to either pass pin 16 through when a DS18B20 is not used, or to connect the DS18B20. I've found having a temperature sensor in various locations of the house is useful (or at least interesting).

Question 1: I haven't looked at the 8574 spec closely. The SDA and SCK pins must operate at 3.3V (because the IO pins on the Network Module are 3.3V), so I think this means the 8574 VDD must be 3.3V, and in turn that will make the IO pins 3.3V. Of course this means devices connected to the 8574 IO pins either need to operate at 3.3V or level shifting needs to be taken into consideration ... just like with the Network Module. Question 2: I think this is correct. Question 3: int not used is fine too.

If you write to me at the nielsonm.projects@gmail.com email address I can send you the schematics and board layout for a test board I built. It is probably not something you want for production use in your house, but it is very useful for me in testing code releases. It has a 24LC1025 and DS18B20 temperature sensors so you'll be able to see how I connect those (or pass through the signals if they are not populated), and I added a number of other footprints and connections for some other experiments.

Mike

[nielsonm236]

This is coming up on my next task list. I bought some hardware to support the development. The first pass on this will be as follows: 1) URL commands only 2) Output pins only. The above is to shake out initial bugs, so @sjorsBe I will need your help to try it out. After the above we'll consider the following: 1) Inputs via URL 2) MQTT and Home Assistant interface (inputs and Outputs). 3) GUI interface to control and read pins. This item may be more complicated than you would expect, so I'd rather not do it unless really needed. It is likely that supporting a GUI interface to set and clear pins would only fit in Upgradeable FW versions, whereas the URL method would likely fit in all versions.

[jmcvieira1]

Hello everyone, I am also interested in implementing a NetworkModule port expansion solution, I currently have seven modules working in my house in different locations in the house and three of them already have all the ports in use. All my boards are currently prepared to integrate the eeprom so I will "lose" two ports currently in use, but I will gain eight more from the expansion board, and I will still have the remote upgrade functionality. I am available to collaborate in whatever way I can.

J.Vieira

[nielsonm236]

The board that @sjorsBe designed is based on the PCF8574 (8 ports) and also adds the I2C EEPROM, Here is a photo of @sjorsBe board (his first prototype) piggy-backed on a HW-584:

To develop the code I bought this item since my configuration already has the I2C EEPROM.

It only adds 8 ports, but is very inexpensive and more can be added in series. The initial code will only support 1 board, and my biggest concern is the GUI to support this expansion in a way the user can understand. I will start working on the code in the next couple of weeks to give us a framework for testing and creating user-friendly ideas. The initial code will likely use URL commands to set up the hardware configuration, but clearly a GUI is needed to configure the additional IO pins. Maybe the additional on the 8574 can be simple input/output without all the code needed for timers and linked pins and so on. Perhaps timers, linked pins, and other features would only be available on the pins that are on the HW-584. At least that is a place to start.

There is also a board based on the PCF8575 which adds 16 pins. Here's an example:

The PCF8575 might also be a future target. Again, what does the GUI look like to handle options?

Mike

[nielsonm236]

@sjorsBe Can you tell me what part number you have? PCF8574 ... or PCF8574A? The "A" version uses different addresses than the non-A version. Mine are all "A".

[nielsonm236]

I'm going to work on detection of both types, but it would be easier (of course) if I only had to work with one. I will also work on detection of up to 4 devices on the I2C bus ... but again it would be easier if it were only 1 device. And of course easier if they were all the same type and not mixed on the bus. I could use some feedback if this is worth the effort.

For a prototype and initial feedback I've implemented as follows: a) You write to the device with a URL command (not GUI). It is of the form 192.168.1.182/83xx where xx is the bit pattern in hex to be output. b) The pin states display on the IOControl page like this: As FYI, the bits displayed are a combination of Output State and Input State. I will have to implement a "Data Direction" register if we want to have both Inputs and Outputs. A DDR would be needed by MQTT and Home Assistant so that the MQTT communication identifies which pins are Out and which are In.

I would like to make a GUI for the device similar to the existing IO Control GUI, but we are going to have a lot of complication and likely not enough space if we want to mix interaction between the existing IO and the PCF IO, or want to have pin names and timers like we do on the existing Browser IO. We could possibly have a separate IOControl page for PCF devices. I will do some sizing tonight to take a guess at what will fit. Simpler is better, and I would prefer that we take a minimal approach with the PCF IO. My suggestion (subject to sizing):

• Separate IOControl page for PCF devices
• Only available on Upgradeable code (as the I2C bus is only in those builds).
• Browser Upgradeable could have IO Names (but no timers to reduce complication).
• Perhaps up to four PCF8574 supported ... not sure how we easily accommodate that in the GUI. Let me know if you think that is of any value.

I can provide prototype builds in a day or so if we are all using the "A" version device. A little longer if I need to detect device type. There are no config registers in the device, so I would have to scan the two address ranges to see if I find anything. Not rocket science, but takes some time to code and test.

Mike

[sjorsBe]

Hi Mike,

For my piggybag PCB I used the PCF8574 – so, not the A version The problem is that I found out that the suppliers here in holland do randomly deliver the standard and the A version. It did surprise me earlier when I got a standard PCF8574 delivered instead of the ordered A version. On my piggybag I used a fixed I2C address, being: 20h. The EEPROM has A0 and A1 linked to 0, A2 linked to 1.

My thinking:

• We are expanding the module to its limits. Mind you: an extra Netmodule unit is around 6 euros and an additional POE -5V adapter (for standard powering the module) is around 3 euros. So for less than 10 euros an additional 16 i/o ports can be added to a domotica solution.
• Due to the fact that a few ports of a module are being used for other purposes ( EEPROM, sensors etc ) it would be nice to enhance the number of ports with a pre defined number of extra ports.
• It would be extra nice if the linked option ( a domotica safeguard option ) could be used in combination with the port expansion option
• But as said, there is a limit to the continuous enhancement hunger of the simple Netmodule.

You did an excellent job when you established:

• Multiple Netmodules with one LAN
• The remote update possibility to maintain the Netmodule
• The MQTT support of the module
• The linked option in order to always have the old fashioned fall back

But sometimes it is enough isn’t it 😊

So I think we should make our ( read: Your 😊 ) life a bit easier: Just support one PCF8574. Forget the PCF 8575. Fixate the address ( probably by two due to the two models there are ) Whenever you want you could release the piggybag layout v2 ( im putting a few capacitors in in order make it all quite nice ) And call it a day 😊

Kind regards

Sjors

Difference between PCF 8574 an PCF 8574A

The difference determines the I2C adresses for read and write;

The A0-A2 bits decide the I2c address

A2

A1

A0

PCF8574

PCF8574A

0

0

0

20h

38h

0

0

1

21h

39h

0

1

0

22h

40h

0

1

1

23h

41h

1

0

0

24h

42h

1

0

1

25h

43h

1

1

0

26h

44h

1

1

1

27h

45h

Van: Michael Nielson @.> Verzonden: zondag 29 januari 2023 22:53 Aan: nielsonm236/NetMod-ServerApp @.> CC: Sjors Beens @.>; Mention @.> Onderwerp: Re: [nielsonm236/NetMod-ServerApp] How to enhance the needed pins for sensors? Can the PCF8574 module be useful? (Issue #115)

@sjorsBehttps://github.com/sjorsBe Can you tell me what part number you have? PCF8574 ... or PCF8574A? The "A" version uses different addresses than the non-A version. Mine are all "A".

— Reply to this email directly, view it on GitHubhttps://github.com/nielsonm236/NetMod-ServerApp/issues/115#issuecomment-1407779324, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARXPVVZOJAL3FSQ5I2DXGXTWU3RDDANCNFSM6AAAAAARAEF7RI. You are receiving this because you were mentioned.Message ID: @.**@.>>

[nielsonm236]

Looks like your formatting was lost in the above, but I know what you meant. Here are the best tables I found for addressing the two versions of the device:

I believe I can scan the bus to look for PCF devices at all addresses across the two PCF revisions, then retain the "valid address" in one byte of RAM (assuming one PCF device is supported). If this works well then in a future revision of the module code we can consider supporting more than one device. For now if someone attaches more than one device I will only talk to the first one discovered. "Always start simple". Since you have the original rev, and I have the "A" rev, I already know I need to support both, and the scan is not difficult to implement.

Above you mention the "linked option". Are you referring to programming with the SWIM interface? Or the "Linked Pins" feature?

[sjorsBe]

Hi Mike I meant the linked Pins feature…

Kr

Sjors

Van: Michael Nielson @.> Verzonden: maandag 30 januari 2023 17:42 Aan: nielsonm236/NetMod-ServerApp @.> CC: Sjors Beens @.>; Mention @.> Onderwerp: Re: [nielsonm236/NetMod-ServerApp] How to enhance the needed pins for sensors? Can the PCF8574 module be useful? (Issue #115)

Looks like your formatting was lost in the above, but I know what you meant. Here are the best tables I found for addressing the two versions of the device: [image]https://user-images.githubusercontent.com/63531544/215535573-f456a912-f7d4-4535-a844-0a05ebb5bbd2.png [image]https://user-images.githubusercontent.com/63531544/215535704-1d68e734-4ead-4c52-b00e-95d98c7620bf.png

I believe I can scan the bus to look for PCF devices at all addresses across the two PCF revisions, then retain the "valid address" in one byte of RAM (assuming one PCF device is supported). If this works well then in a future revision of the module code we can consider supporting more than one device. For now if someone attaches more than one device I will only talk to the first one discovered. "Always start simple". Since you have the original rev, and I have the "A" rev, I already know I need to support both, and the scan is not difficult to implement.

Above you mention the "linked option". Are you referring to programming with the SWIM interface? Or the "Linked Pins" feature?

— Reply to this email directly, view it on GitHubhttps://github.com/nielsonm236/NetMod-ServerApp/issues/115#issuecomment-1408959476, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARXPVV2UITR336RWFN4SAI3WU7VL7ANCNFSM6AAAAAARAEF7RI. You are receiving this because you were mentioned.Message ID: @.**@.>>

[nielsonm236]

OK - I think the best way to implement Linked Pins on a PCF8574 is to restrict the Linking to that device. Perhaps only allow linking of pin 1 to 4, 2 to 5, etc. That would resemble the pattern used on the Module pins where we only allow linking of pin 1 to 9, pin 2 to 10, etc. Later if we decide to allow addition of more PCF devices the same algorithm would be applied to each PCF device. I think this keeps the code modular and in sync with devices that are added.

Thinking further, if in the future we support more than one device the code will probably have to organize them by their I2C addresses, from lowest address to highest.

Coming back to the "initial design with one device": I will need to come up with a naming schema for the pins as they appear on MQTT and in Home Assistant. I think I can just follow the same naming convention that is used now, continuing the pin IDs stating with pin 17 and incrementing upward. There shouldn't be any need for MQTT or Home Assistant to be aware of the hardware those pins are implemented on.

Now, since we've decided support of Linked Pins on the PCF8574 is desirable, I also know we need to define a "Data Direction Register" for the PCF8574. The PCF8574 hardware doesn't care about this due to its use of quasi-bidirectional IO. But MQTT and Home Assistant care: Auto Discovery and Publishing need to know if a given pin is an Input or and Output. So, in addition to a IOControl page, the PCF8574 needs a Configuration Page just like the original module pins have. A thought is to just combine all this with the existing IOControl and Configuration pages, but the code complexity will increase significantly. Separate pages to handle the PCF device will tend to maintain modularity in terms of code and in terms of a more intuitive user experience.

[jmcvieira1]

I agree with what you propose for the operation of the PCF8574 As soon as the boards I bought arrive I will be available to test the firmware. J. Vieira

[nielsonm236]

@jmcvieira1 Sounds very good! Thank you! It will be interesting to see what chip revision you get. I now have the search loop working for both revisions of the device (although I can only test with the "A" version). It's fairly simple code that steps through the addresses for both devices so I expect it will work fine with either version. But, "Untested code != Working code". :-)

Now I will see what I can do with the GUI.

[nielsonm236]

One more fundamental limitation - this should have come to mind as soon as we started but I completely overlooked it until now. Each IO pin must have a "Pin Control Byte" stored in the on-chip EEPROM. There are only 17 bytes left at this time. So, this alone may cause us to only implement a single PCF8574 if we want the added IO to have characteristics similar to the 16 IO already implemented.

Having said that, since we are implementing the PCF8574 ONLY on "upgradeable" configurations, we have the very large I2C EEPROM that can hold a huge amount of non-volatile data. So I believe I'll store the Pin Control information for the PFC in the I2C EEPROM. Yet another point of confusion for anyone trying to figure out what this crazy hack programmer did, but I will document as usual. And we'll save those 17 bytes for anything in the future that needs to run on the Non-Upgradeable versions.

It actually makes good sense to store non-volatile information needed for the Upgradeable builds out in the I2C EEPROM. I will reserve space in the I2C EEPROM for this function. And now there is no fundamental limitation.

[nielsonm236]

Just an update so you'll know I'm still working on this. Adding pins via the I2C interface, particularly when we want them to perform functions in the same way the pins on the STM8 processor work, ends up touching a very large number of functions. Keep in mind this code started out as a "pin controller". So most of the functions were designed with the concept of "16 pins" directly accessible via the STM8 registers. Now we add 8 more pins, accessible via the I2C bus, so a lot of functions working with 16 bit variables now have to work with 32 bit variables (to track 24 pins). This includes GUI access, MQTT access, startup configurations, invert functions, de-bounce functions, linked pins, power on defaults ... the list goes on and on. Simple in concept, but within the code it is a lot of touch points.

The driver to operate the PCF8574 was simple and only added about 200 bytes to the code. All the other changes are going to be a lot bigger than I expected.

I am making good progress, but test will be difficult. Fortunately I'm isolating all added code via #if/#endif compiler directives, so I can build with and without the new code.

Mike

[jmcvieira1]

Hello My PCF8574 board´s arrived today the on board chip is the PCF8574T

[nielsonm236]

The "T" just refers to the package type. So you have the original addressing. Doesn't matter. The code should detect both address ranges. Today I think I got the last code change in and compiled. Test is next ... and bug fix ... and ...

[nielsonm236]

Addressed in 20230305 1816