Topics created by Christian

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

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

Hi @Martin-Kudláček ,

Sorry to wake this one up again.

But i hope you can reassure me a little bit more.

This high load kind of freaks me out, so i would really like to put a finger on whats happening

I have a lot of Neurons running (at least 15+) with very low load averages, always under 0,10

I also have a lot of (newer) Neurons running (some 20+) with very high load averages, like @cristian mentioned, way above 1,20

I haven't got influxdb running on those, and i'm not doing weird things as far as i know.

The only obvious difference I can find is that in the low-load unipi's ther's still the old drivers called NEURONSPI, and in the high-load unipi's they are called UNIPISPI.

I'm not sure this is the culprit, but it seems that the OS version is not really an issue

I have Debian stretch on the older ones, with low load, but i have also stretch installs that show the high load.

All unipi's with Buster have the high load for sure, but they're all UNIPISPI according to dmesg

Is there anything you are aware of that justifies the load difference between UNIPISPI and NEURONSPI?

Or do i have to look further... Or should i really not worry about this?

Most of these unipi's are in production environments long drives away, so if there's something to be fixed i would try to get that done before they break...

Thanks a lot, Tony, Fireware Netherlands

)

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

Best regards,
Martin

Hello @Christian,
the precision of the sensors cannot be set via Evok. The only way is to do it by some external tool, e.g.: https://raspberrypi.stackexchange.com/questions/14278/how-to-change-ds18b20-reading-resolution.

If you cannot read value of any sensor, then it looks more like a HW issue. One faulty sensor can kill whole bus. I would suggest to try one sensor at a time and see if you could read value from all of them.

The I2C interval isn't affected by the number of sensors or the time they need for the response. The underlying OWFS reads the values sequentially, one sensor at a time.

Best regards,
Martin

Hi @christian,
frankly, we don't use event based tasks at all, since it makes the program harder to read. What is your motivation to use them?

I must say that I don't understand the first example and from what I see it leads to oscillation:

0_1550739082329_ac247ff3-0c9f-4ffd-91b7-dda8d62cef51-image.png

For me, simply using the toggle in Freewheeling NormalOperationTask is straightforward and error free. We use it like this in many situations.

If you want to directly wire DI to DO/RO, take a look at our Direct Switch functionality: https://kb.unipi.technology/en:sw:01-mervis:advanced-modes-of-digital-inputs-hidden

Hello @christian,
yes, it is possible, but it requires to write your own parser of data in ST code. This is an excerpt from help files of how it could be done:

0_1550561083622_44254d67-c742-4f9c-ae93-f7f4bf448932-image.png

Sorry for the printscreen, but copying from help files loses the end of lines...

Martin