Plugin port expander

---

After a year I am back in business Apologies to everyone who was looking for me. I have been dealing with really difficult family problem. Everything is ok already. Sorry again.

And now to the point.
I want to write a plugin for the MCP23017 and MCP23008 (i2c version). Primary target.
http://www.alldatasheet.com/datasheet-pdf/pdf/195324/MICROCHIP/MCP23017.html
And for PCA9685 16-channel 12-bit PWM / Servo Driver.
http://www.alldatasheet.com/datasheet-pdf/pdf/293576/NXP/PCA9685.html
And also for Shift Register: 74 × 595 and maybe even more.

I would like to use wirigpi library which can control it.
Have you experience how to do it best? Somehow I do not want Davat module wiringpi to each plugin that you create. Can it somehow be shared between the plugins?
Or isnt wiringpi in pimatic for itself already?
I have chosen this modul for implementaion: https://www.npmjs.com/package/wiring-pi

Thanks for any advice.

I looked briefly at the MCP23017, initally just did shell execute for what i needed (which was what my old php script did as well…). But I did see there are i2c stuff in the nodejs packages system, and aslo native i2c libraries. And there is a pimatic plugin for an i2c display as well.

https://www.npmjs.com/package/i2c
https://www.npmjs.com/package/mcp23017
https://github.com/pimatic/pimatic-lcd

Maybe those will help you get started.

@wutu See https://github.com/rwaldron/johnny-five/blob/master/docs/expander-MCP23017.md

A pimatic plugin for Johnny Five will be available in a few weeks and the virtual board could be easily integrated.

@wutu said:

After a year I am back in business Apologies to everyone who was looking for me.

good to have you on the project again
and really no need to apologize!!

Thanks for the reply.
I sowed these modules, of course, and some of them also. Unfortunately some things that I want in the future to implement the modules are not even written, but it can be controlled WiringPi.
So either implement well over WiringPi. Just because then I’ll watch the development of only one module and not be six or more

Therefore I will put the question again and hopefully better;)
It WiringPi some already implemented in Pimatic (I know that it requires a module pimatic-dht-sensors) or under consideration?
And it is better to write one big module (for example pimatic-wiringpi) or rather more narrowly focused modules (for example pimatic-mcp230xx (i2c versions), pimatic-mcp23Sxx (SLI version) pimatic-pca9685 and so on …)?

Or module for wiringpi (without support chips) and then modules that use it?

I do not want to make a mistake right from the beginning. There certainly will do a lot then in CoffeeScript: D

Thanks for the answers

P.S. Module PCA9685 I want to do for this card: http://ledsee.com/index.php/new-products/16-channel-i2c-fet-arduino-schield-pca9685-detail (connected to Rpi, not to Arduino). And for fun and dev I ordered this: http://www.banggood.com/CJMCU-PCA9685-16-Channel-PWM-Servo-Control-Module-12-Bit-Fm-I2C-p-988317.html

@mwittig On the weekend I was more on studying johnny five and wait for the plugin.

@wutu Now, I have a MCP23017 expander for testing and manged to set it up with an array of eight LEDs. I am now working on the integration of the expander code as part of the plugin.

@wutu you can look at the Pimatic-homeduino source code. This has an nice abstraction layer and used on the rpi the wiringpi library.

But when Jonny five did the job then you don’t have to write your own plugin.

@Icesory said:

you can look at the Pimatic-homeduino source code

I don’t think we have expander support with pimatic yet eventhough wiringpi generally supports this. Johnny-Five already supports 9 different expanders. The integration into pimatic-johnny-five is just a matter of a few days.

@mwittig Hi, I already have integration Expander almost done https://github.com/wutu/pimatic-johnny-five. No PWM and Analog, PCA9685 is still on the way from China.
PCF8591 I just ordered.

@wutu said:

Hi, I already have integration Expander almost done

Ah, that’s great. I didn’t notice that. As far as I can see you have created new device classes for expander button / relay / contact / switch. What I would like to suggest is to implement the expander as a board type, say a “ExpanderBoard”. This way, the board can be used with all device classes and there is no need have special expander device classes. I did a proof of concept implementation for this, but now I need to extend BoardManager to handle the ExpanderBoard properly. The challenging bit: The initialization of a ExpanderBoard must be different as it can only be created if the controlling board is ready.

@mwittig

I thought about it put everything into one device. Not a problem to merge. Like in pimatic-GPIO.
I’m not sure whether Expander is a separate board. In Johnny Five is definitely not It takes him as an extension periphery. Or not?

Regarding PWM, I would like to implement things from pimatic-piblaster. (CIE1931, step periods, etc.).

@wutu said:

In Johnny Five is definitely not

Well, there is, i.e., five.Board.VirtualBoard which is a helper to create a Board for the expander. See the code snippet below.

var five = require("johnny-five");
var board = new five.Board();

board.on("ready", function() {
  var virtual = new five.Board.Virtual({
            io:  new five.Expander("MCP23017"),
            board: board
        });

  // This creates an array of eight LEDs. As you see, each LED references
  // the virtual Board
  var leds = new five.Leds(
    Array.from({ length: 8 }, function(_, i) {
      return new five.Led({ pin: i * 2, board: virtual });
    })
  );

  leds.on();

  this.repl.inject({
    leds: leds
  });
});

As virtual is a Board (what I called ExpanderBoard in my previous post), it can be used along with pimatic-johnny-five device classes! However, as explained earlier, the EpanderBoard can only be created if the board is ready.

Yes, I use this procedure. Just saying the board is not virtual board.
I understand well, therefore, that after inclusion of the virtual board to board manager does not need special device and it will be possible to use existing ones?

@wutu said:

and it will be possible to use existing ones

Yes, that’s what I have in mind, however, it will require some refactoring of BoardManager. The advantage is, however, there no need to have special device classes for the expander

As the first path I chose implementation over boar manager, but then I decided to devices seems to me that the boards are poled J5 something with CPU and Expander to me seems more devices

As
Board> device
e.g.
ESP8266> LED
ESP8266> 8x Expander
Arduino> Servo
RPI> Expander1 and Expander2 (my case)
and so on

But it’s just angle of view

@wutu I am wondering to what extent you have tested your expander device classes with the actual hardware already? Regarding the switch I found the J5 expander implementation does not support querying the state of an output pin. For this reason the switch device will only work if board.remote is set to true.

I also had some “lessons learned” about wiring the expander as it was the first time for me. Btw, I found the expander will only work in a reliable way if the address pins are grounded. Before doing that I experienced some commands got lost. Now it works rock-solid for me. See also https://github.com/rwaldron/johnny-five/issues/1009

Regarding my implementation work, I have done a first impementation of the extended BoardManager which already works very well (I am going to push that soon). So far, I have only tested test with the switch. Next thing is to test the relay and the inputs.

I’ll keep you posted.

@mwittig said:

@wutu I am wondering to what extent you have tested your expander device classes with the actual hardware already?

Besides the presence-sensor I have tested everything I wrote. Everything works OK.

Regarding the switch I found the J5 expander implementation does not support querying the state of an output pin. For this reason the switch device will only work if board.remote is set to true.

I also found

Regarding my implementation work, I have done a first impementation of the extended BoardManager which already works very well (I am going to push that soon). So far, I have only tested test with the switch. Next thing is to test the relay and the inputs.

I’ll keep you posted.

I was curious and also I test with raspi-io.

@wutu Thanks for your feedback! Meanwhile, I have also tested with ContactSensor and Button. While Button worked right away the ContactSensor had caused problems as it is also using the unsupported query method. Given that Button and ContactSensor are almost the same, I think I’ll refactor it to a single device type - just ContactSensor with the Button features included. It is great, you’re also testing with Raspi-io! Please keep me posted on this.