Ok, I understand. For now we will burn some cpu to avoid lagging :) Setting polling interval to 8 or 9 works for me at the moment.

Although in my opinion if you want to be taken seriously on the market, you really have to improve this part. Other than that, so far I am really happy with the device.

Thanx for your replies and support.
Regards,
Matic

Hi @tomas_hora,
I am continuing this discussion that was started in here in a separate topic as I think it might be useful for future reference.

We have already established that above a proper hardware with I2C interface running at 12MHz, there is a bottleneck - a polling mechanism which scans for changes and triggers updates on all interfaces. The polling frequency can be adjusted in /etc/evok.conf.

By default the polling freq. is set to 2 resulting in delays up to 0.5s before an input change is propagated to the websocket interface.

Setting it to 7 results in a let's say acceptable delay of up to 0.1s but it also increases cpu usage above 10%. Even though the delays are now acceptable it still happens that a short key press and release is not reported to the websocket at all (counter is increased, but the change is not reported).
I have measured the key press-release pulse duration. With my wall pushbutton I can not make a pulse shorter than 80ms, typically lasting around 100ms. Missing a pulse of 80ms makes this device useles for many industrial scenarios...

So what can we do to detect shorter pulses? One option could be to use counter change as a trigger.
DirectSwitch is not an option... I want some logic between input and output.

You really don't have a hw change interrupt wired to raspberry gpios that would forcre immediate SPI update ;)? I am not familiar with rpi interrupt mechanisms, but from a perspective of an embedded systems designer this seems like the way to go.

Best regards,
Matic

@tomas_knot said in Setting filter corrupts the websocket message:

As for the input change report - it is event-driven. Essentially there is a global cache which gets read via regular SPI polling in Modbus blocks, and after each read the delta is sent in a message. It should be noted that internally the individual boards are capable of much faster processing, so e.g. counter changes or DirectSwitch are not dependent on polling speed. The limiting factor is the raspberry processing speed, the SPI bus itself runs on 12MHz.

I am asking because with a simple websocket script which toggles a relay for every change of an input I am getting a random delay from 0 to 0.5s between key press and relay toggle.
0.5s is a lot and I would really like to keep the latency below 100ms. What do you suggest?

Not sure how to check version, but I am using the following unipian image UniPian-Neuron-OS-2017-11-24.zip.

Hello
I've come across this strange issue:
If I don't set any filters, an input change is reported through websocket like this:

[{"counter_modes": ["Enabled", "Disabled"], "glob_dev_id": 1, "modes": ["Simple", "DirectSwitch"], "value": 0, "circuit": "3_13", "debounce": 50, "counter": 52, "counter_mode": "Enabled", "dev": "input", "mode": "Simple"}]

While setting the filters to input only

'{"cmd":"filter","devices":["input"]}'

Returns this:

["counter_modes", "glob_dev_id", "modes", "value", "circuit", "debounce", "counter", "counter_mode", "dev", "mode"]

Am I doing something wrong?

Another question that I have is whether sending input change report is event driven or things are sent through the websocket on regular intervals? Sometimes I am experiencing longer delays that I would expect.

Hello,
yup, sending cmd:all every minute prevents the connection drop.

Even though, I don't feell like writing a state machine for blinds in node-red is a good idea. I will test this behavior while migrating to python along the way.

Regards, Matic

Hi @tomas_knot,
I have a simple script in Node-red although i will probably be writing a python script sooner or later.
The connection is reconnected immediately but the filter settings are gone and I have to reapply them. This happens a minute or two after filters are applied.
Does filtering out all the unnecessary streaming actually improve response time of digital input notifications?

Thanx and regards
Matic

Hi!
I just bought the Unipi and I am getting familiar with possible interfaces. I must admit I am a bit dissaponted that there is no out of the box support for mqtt, as it is nowdays defacto standard for home automation, but it looks like websocket should do the job.

Enough introduction, let's get to the point: After I set the filter to DI only, the incomming streaming stops as expected. But after some period the connection drops. What could be the reason for that? Is there an IDLE timeout? Should I be sending some keepalives? I haven't played with watchdogs; I suppose they are disabled by default?

Thanx and regards,
Matic