Hello @Pavelf,
if I understand you, the problem with logical states synchronization occurs during the same GPIOs toggling from more than one different applications/libraries simultaneously (Evok, pigpio, FHEM, WiringPi...). The Evok always returns internally-cached values which can lead to described behaviour under certain circumstances. Also, the pigpio internally used by the Evok has been upgraded recently. I will check this more thoroughly and let you know.

Hello @stephane-clavel,

it seems you have not some kernel modules loaded. Try lsmod command - you should see unipi, at24 and i2c_dev modules loaded. If not, follow the steps below.

As the first step, try to reinstall appropriate package (assuming you have the unipi repository already sourced):

sudo su apt-get install unipi-kernel-modules

As the second step, reboot the controller.

You can try to install unipi-kernel-modules package containing precompiled modules (while the unipi-kernel-modules-dkms package is removed automatically).

sudo su apt-get update apt-get install unipi-kernel-modules

Current version of the package is 1.32.1.xxxx

@boy-lenssen Yeah, that's something we are working on to protect bricking the units during the FW upgrade process. If the RUN led is dead, send it to us so we can reflash the FW.

Hi again and thanks for the help,
I've used ModbusTCP now and the input / output rates are much better, if someone's interested:
Reading only = 2,5 - 7,4 ms
Reading and Writing to another pin = 7 - 15 ms
Reading, Processing the measures, and Writing to another pin = 6 - 18 ms
I used Analog Input 2.1 / 2.2 and Analog Output 2.1 for my application

Hello @HarishKumar,
sorry for the late reply.
Evok in version 1 is no longer supported (didn't you mean Evok-mini?). The current version of Evok is 2.1.x. As the first step, you should try to download and install the latest version via Debian package subsystem:

apt-get update apt-get install evok

Or directly:

wget https://repo.unipi.technology/debian/pool/e/evok_2.1.2_armhf.deb dpkg -i evok_2.1.2_armhf.deb

Right now it's best to use the install method starting from Raspbian (but currently only Raspbian Stretch). We are currently working on image build system which helps us to get faster releases of images and application updates (debian packages).

Hello @valtert,
the description on the page is misleading. The real situation is this:

Analog output on Group 1 is capable of outputing 0-10V, 0-20mA and measuring resistance up to 100kOhm
Analog outputs on Group 2 and 3 and on the extensions are only capable of outputing 0-10V

Same goes for Neuron and Axon product line. If you need second AO in current mode for your project, you have two options:

add a second PLC as a "dumb" extension and communicate with the master PLC via ModbusRTU, ModbusTCP or SSCP purchase a 3rd party ModbusRTU IO module, such as this: https://www.advantech.com/products/gf-5vtd/adam-4024/mod_5e18f39b-38ef-4033-98f9-1ede917139ee

I am sorry for the incovenience, we will fix the product description shortly.

Best regards,
Martin

@knebb said in Need Some sort of Jumpstart:

it writes the state as 0 or 1 into each of the uint8_t .

Or, using semantic constants, as FALSE and TRUE.

Directly using bits would be really slow and error prone (and a nightmare for language bindings).

Ok, I'll do it on the board then.
I'll take my chances communicating directly with the modbus tcp server instead of using Evok's layer.

Cheers,
Ronan

Hi @martijn-hemeryck, those are great news! I'm glad we were able to put it together, together:) I'm looking forward for your results.

Martin

I took up the sysfs-based approach in my own (golang-based) project: https://github.com/mhemeryck/unipitt

Basically, it does active polling on a series of files, representing the different inputs and pushes out an MQTT-event in case there's a change.

Hi @anders-kjellström,
it works, you can check in the default installation of the Evok:

0_1560149083570_115de405-bd5a-4d14-b1f8-b0f9913f3249-image.png

Do you have some example where the aliases don't work?

Best regards,
Martin

Yes, it is clear now. You have to implement this kind of functionality by yourself as Evok does not offer it.

@juntiedt said in MQTT to unipi Control Panel:

As the flow is to big to upload I am just sendig a picture. Let me know if you want to get the flow directly.

Hi @juntiedt, it looks like a very great job! Could you consider hosting the file and provide a public link? You might for instance use a Dropbox / pCloud public link, or a GitHub gist.

If anyone has ideas for improvements please let me know.

I think it might be possible to parametrize the flows with variables, in order to avoid repetition. At least, it seems it was done this way by @Jan-Teunis here:

https://forum.unipi.technology/topic/735/node-red-flow-evok-to-mqtt-to-evok

@tomas_hora I installed a clean OS from UniPi website and everything works.