It is possible, but it requires using our image instead of Raspbian. You should be able to use /sys/devices/platform/unipi_plc to find out more information about the system, or simply run "sudo dmesg" after boot, as the image driver performs automatic diagnostics.

@tja said in evok still not stable, inputs will not cause events after some time, restart required:

i took the opportunity to make a walk through the house checking all the switches and sadly (from a debugging point of view ofc :D ) all switches work atm.
i will report any new problems and attach evok's logs, neurontcp's status and ps fax asap.

in the meantime, thx for your efforts to help me. i would really like to put this bug ?!? to rest.

tia,tja...

It's really an odd issue. I hope we can get down to the ultimate cause, it definitely looks like a bug. It's just odd that no-one else has reported the same problem before, either here on the forum or directly via email (which is, statistically speaking, the more frequent method of asking for support).

I really am not sure how this happens. I think it may be due to system load, but since as you say OpenHab is not on the system I am not quite sure why this is. Could you please run

ps -fax

when the system hangs, and post the output here? It could show us the system load in that case.

What's the speed of the inputs? When it stops reacting can you trigger an input manually, i.e. by briefly connecting 24V to the input?

I wonder if it couldn't be due to the scanning frequency. At least in part because the LEDs light correctly and there are no errors. I don't believe anyone else has encountered issues like you describe before.

Could you try restarting OpenHab too? It's possible there's a hung thread somewhere perhaps.

@Boy-Lenssen
That definitely looks like a problem with UART settings, as no RX on the Neuron indicates that there is no response from the extension, not even an error response (which is what occurs when e.g. reading wrong registers or issuing invalid commands).

Could you try using the latest version of EVOK? It is possible that some recent changes will help fix the problems you are seeing.

Hi @alydersen,

The format is quite simple; you can use the GUI to set the alias to test it out. The alias is url-encoded in the following manner:

• spaces are converted into underscores
• an al_ prefix is prepended to the alias
• other url-invalid characters are not allowed

The web GUI then performs the reverse of this process.

In particular, the prefix must be

al_

exactly in order for the alias to be accepted.

Hi @TriathletC!

You will need to use the UniPian image for CODESYS, but you will also need to buy the CODESYS for Neuron plugin.

For more information see the UniPi Neuron compatibility section on our CODESYS SW help section

Hi @alydersen,

Unfortunately setting an alias on 1Wire sensors (though not 1Wire extensions, which is why the option of aliasing 1Wire devices exists in the first place) is not possible, as they are detected dynamically, and lack proper device names which could be aliased in the first place.

This is not the first request for this feature, but right now we unfortunately have no plans of adding it. The solution I would recommend to you is to rename the device in your client website/application instead.

@mdturnerphys

I am aware of the function, but as you saw it is not quite up to the task. It should work much more robustly in the next Mervis release, but we unfortunately do not have a firm release date yet.

@alydersen

It looks like there has been a recent bug in EVOK which caused the hardware definitions to be parsed incorrectly. What I said above does stand, but the error is a software bug on our part.

You will need to download the release 2.0.7 in order to fix the problems you are seeing. The source of the error is a missing condition which causes UART hw_definitions to break, though only some of the time.