@Andrew-Watson said in Evok problem getting I/O boards data:
Some additional information, since I had time. I flashed a new sd card with a brand new raspbian stretch lite image (latest version, 2017-11-29)
installed git and updated the system
sudo -s
apt-get install git
apt-get update && apt-get upgrade -y && apt-get dist-upgrade -y
raspi-config and changed the hostname
Then installed the latest evok version (from commit 8a14c95 it seems).
Selected website port 80
Internal API port 8080
Install for Unipi Neuron (I have the S103)
No WiFi
Reboot
And this time it works... I don't know if this is due to something that was changed in the last commit (between 11am and 1.30pm today) or simply not installing the gpiozero library.
It's quite likely it may be the GPIOZero library. Generally speaking software connected to hardware in a direct manner (with its own drivers etc.) is considerably less compatible among itself than other software. We test EVOK internally on clean Raspbian, as well as with our own image, which is based on the Raspbian Zero; for these combinations, along with some simple software (in fact EVOK installs vim itself), the software does pass testing (with occasional edge issues e.g. the light sensor issue recently).
As to a guess why the GPIOZero library could be causing issues - we use 4 of the GPIO lines on the RPi to expand the primary SPI bus with interrupts and an extra device select slot. This (among other things) is done through the device overlay installed by EVOK, but it's possible that other software (at least one which is set up under root privileges) might change it, particularly if it deals with GPIO functionality.
The latest commits only changed functionality related to the Sedtronic WTS DS2438 1Wire sensor, so it's very unlikely to have caused the problem. The issue you (and @tempurpri) are seeing is due to the expected boards not being found on the SPI bus - this can be because the SPI bus does not function correctly for some reason, or because the I2C EEPROM which stores data about which boards are expected does not function correctly.
@tempurpri said in Evok problem getting I/O boards data:
@tomas_knot The incompatibility with Codesys (the one you mention and the port incompatibility) would be an understandeable reason for the problems I have....had I not managed to have a working setup of Codesys for raspberry and evok running in the last month.
Unless the 1-wire incompatibility between the two only becomes problematic with time (I'm not sure how that could be), then that was not the case for me. Just to make it clear Codesys and digital signal readout worked for me ... Modbus acces and the web interface. I needed that functionality only occasionally, so I'm not sure when it stopped working, but it was during the last month. Neither Codesys nor evok were re-installed nor was there any change in their configuration.
I'm trying to find out what happened and especially try to make it work again.
@tomas_knot @tomas_hora I understand that proper codesys integration is coming, but unless it's coming during this week it won't help my application. Unfortunately that's the timeframe I'm looking at, nothing to do with with Unipi itself.
OK, so if codesys 1 wire driver is the suspect, is there a way to check that and maybe disable it within the Codesys editor ?
I was assuming you have a 1Wire UniPi expansion board, which would not work correctly with Codesys. If you do not, it may still be possible to get it running. But first - does the device function correctly with a clean non-Codesys image? If yes then we can confidently say the issue lies with Codesys, and proceed from there.
