Domoticz

Hi all,
I'm facing the problem that spidev0.0 is taken by my display device (2.2" ILI 9340 based). I have tried to move it to spidev0.1 by modifying device-tree overlays but so far without success. The alternative is to move the PiFace to spidev0.1, this is easy but requires a source code modification which of course gets overwritten at every update. Therefore my suggestion is to make this configurable. The easiest way to do this is using the piface.conf file, for instance by adding an extra line like "device=spidev0.1", meaning that all subsequent lines apply to that device, this would even allow to have more pifaces on the RPi by using both CEs. Another option would be to have different piface.conf files for each bus/CE (e.g. piface00.conf, piface01.conf etc.). This way the config files stay compatible (apart from the name). A third way is to select the interface when adding the piface hardware in domoticz (similar to selecting a serial port), this however I don't know how to do and would require some help. My personal preference is the first option which can even be extended to i2c busses (of course using the MCP23017 instead of the MCP23S17).
Does anybody have more ideas on how this problem could be tackled or a specific preference for any of my solutions?
Thanks,
AW

I've added additional settings to the PiFace code before, so I might be able to help you with this. I've used the PiFace in the past and I've got the hardware laying around to mess with. I've never fiddled with spidev changes, so can you explain how I can move the PiFace to spidev0.1? Does that require physical modifications or jumper settings on the PiFace?

As for the three options, I'd go for the last option, have a bus-select dropdown when adding the PiFace in the hardware screen (defaults to spidev0.0). In addition, a textfield with the config file to use (default to piface.conf), relative to the main domoticz folder (where it is stored right now). This way, everything remains compatible with existing setups.

Thanks Bob,

Yes it requires hardware modification, AFAIK the SS pin on the MCP23S17 is hardwired to CE0 so you will have to cut a trace and re-solder. I don't have a real PiFace so I can't help you with that any further. I used a prototype board with a bare MCP23S17. In my current project however I want to use an ATMega in SPI slave mode, I will probably go for an Arduino Pro Mini 3.3V because it already has the resonator and capacitors and is hardly bigger than the '328 in DIP. The advantage is that pulse counting can be more accurate because I can do the sampling in the Arduino (using high sample rates, interrupts or whatever) and pass the pulses to the RPi at a moderate pace (I would know when the Pi reads the PiFace), that way I will never lose pulses. I could also use the Arduino to translate PiFace IO to/from e.g. KAKU commands. And a protoboard with Arduino costs less than a real PiFace.
I agree that solution 3 is the more elegant one, the bus and config file name could be passed e.g. to a constructor of CPiFace, my first problem is that I have no idea where such constructor is called and that I will have to make changes to the add-hardware page in the web interface, something with which I have no experience. The new information probably needs to be stored in the database too. Therefore, until I get some help, I will start working on option 1 which is also compatible because in the absence of a device= statement it will default to spidev0.0. So the only problem occurs when a piface.conf file contains such statement while still using the original software. So even if the new software would be in the main trunk, old config files (which are of course not updated) will remain working.
Nevertheless help with the implementation of option 3 is very much appreciated.
Also, if somebody knows how to move the pitft display driver (from adafruit, based on notro) from CE0 to CE1 than please share this with me.

As this is a very specific tweak which requires soldering and tampering with the PiFace board I think the best solution for you is to add support in the config file and not bother "standard" users with additional confusing settings (yes, I changed my mind about option 3 ). Since you're already on to it, I'll wait until you get stuck (which I bet will never happen) before attempting anything myself