Hello @henkka,
is it something you are able to demonstrate? The best thing would be, if you could send us the SD card image and we would be able to replicate the problem.

Thanks for the answer in advance,
Martin
support@unipi.technology

Hello @lukec,
Docker is meant to be a platform for running HW independent SW. The Evok depends on the UniPi ModbusTCP server, which depends on the kernel module, so it is pretty much down to the hardware kind of application (heavy SPI and I2C communication). You can "enclose" your application with certain Evok version and configuration into Docker container, but it will still require manual work on the Docker host to make it transportable accross different UniPi controllers.

Martin

Hi @martijn-hemeryck,
We changed the repository's name to unipi-python-lighting and it resides here: https://git.unipi.technology/UniPi/unipi-python-lighting

Hello @christian,
the websocket interface sends only values which has changed. To request all current values, send this command at any time:

{"cmd": "all"}

Best regards,
Martin

Hello @christian,
it is hard to see from the picture, but it looks like your sensors are connected in star topology. This is highly unrecommended and you can read more about it here: https://www.maximintegrated.com/en/app-notes/index.mvp/id/148

Best regards,
Martin

0_1551607450428_unipi-mqttt.JPG

Hello @christian,
it isn't, but I just add it to the list of feature requests:)

Best regards,
Martin

Hello @cvrcejir,
I am sorry but I have to confirm that. Moreover, the Evok 2.0.7i brought even more errors than it fixed, so please, downgrade to the 2.07h: apt install evok=2.0.7h.

I am sorry for the troubles,
Martin

Hi @rick3ry,
the evok only engages the pull up resistors via pygpio library. There is no other magic from our side, so you need to consult the behaviour of the diozero library with its authors.

Thank you for understanding,
Martin

Hello @bibabutzemann,
the 1-Wire pinout on our PLCs is documented here: https://kb.unipi.technology/en:automation:02-glossary:1wire-hidden

Since your sensor is not original from UniPi (we have 4 wires), I can only guess the function of the wires:

red: Vcc
black: GND
yellow: 1-Wire

But you need to refer to the documentation of your sensor, or do the blind test which may damage your sensor.

Best regards,
Martin

Hello @marko2276,
only the local PLC IOs are exposed via the SysFS at the moment.

Best regards,
Martin

Sorry Tomas, maybe I have problems understanding watchdog operation. I have the new evok.py in place and when trying to activate (not to perform manual reset) the watchdog on the web interface I get:

[I 190116 08:04:54 web:2064] 304 GET /rest/wd/1_01/ (::1) 4.81ms [I 190116 08:04:59 neuron:1296] Performed reset of board 1_01 [I 190116 08:04:59 web:2064] 200 POST /rest/wd/1_01/ (127.0.0.1) 13.44ms

The watchog stays inactive. Sometimes my Neuron stops working (every second LED on the main unit is blinking) and a manual power cycle is needed.

Hi @clueless,

Glad to hear it's working - I'm not sure what exactly could have gone wrong, as everything seemed to be okay in the logs, which left me, well, quite clueless.

I was hoping to get back to you with some more information, but frankly could not think of any simple checks to be made. At any rate - I am very glad to hear that it is working for you now!

Hi @joerg,
the UniPian image is indeed broken and not just the download file. There are problems inside, so we removed it from our website and until further notice, it will not be available.

You can use stock Raspbian and just to install our packages. To learn how, read this tutorial: https://kb.unipi.technology/en:sw:04-unipi-firmware

Best regards,
Martin

Hi @majorcsa,

I have added this feature via a config file switch to the Master branch of EVOK. As I've mentioned before it may take a while to propagate to our releases and debian packages, but you should be able to test it out manually.

I hope this helps,
Kind Regards

Hello @stoeffel,

If this happens, you do not need to reboot the whole neuron, just reset the 1Wire bus using Modbus or OW_off variable in case of Mervis.

Let us know what you find out.

'nother update: giving it some thought, I quickly wanted to see if I could do the same stuff again in go, so here goes another POC: https://github.com/mhemeryck/unipitt/blob/37b9a07bc570301c2a11836526df1a2be8b21647/main.go

(Don't mind the project name though, I've sort of ran out of original names, I guess)

Anyways, performance seems much better in this case. I figure I'll put my efforts into polishing this project as it seems to be the simplest, fastest, most robust.

I did notice however when toggling one of the DI's, that another DI also got toggled somehow, still need to investigate that further.

Thanks for continuous feedback, this actually adds a lot to me for the overall unipi experience!