@zdenek_jotio Success!!
I've changed your inject node to "1" instead of "1_01" and it's worked.
Finally getting somewhere.... Changing the nodes is working on all examples now
Brilliant, thanks for the direction

JP1 has been mounted, sorry was faulty information.
But finaly i found the problem: 5V GND was not connected
to the UniPI power plug, only on the mini USB.
Thank's for you help.

best regards
Michael

@kolopes Exactly... But the relays in Neurons are only 5A

@David thank you

@tom84
The mA problem is an issue with older hardware. UniPi Neuron for CODESYS will be updated to resolve the issue at the next service release.

Please note the issue does not occur on current Neurons. No Neuron products shipped since the release of UniPi Neuron for CODESYS will see this problem.

It should only disconnect if either a certain number of requests fails to reach the client; or no successful messages have been sent over >10 minutes, while there have been failures during that time.

The actual implementation/behaviour is from the tornado.websocket library, albeit we use a slightly older version of Tornado.

If you do have the time to investigate further we would quite welcome the feedback. We have put this on our list of things to improve in the future, but right now I can't give you any more specifics.

UniPi doesn't supply DALi bus power.

As to the DALI/light bus dychotomy - I believe that this has been corrected in the Master version of Evok on Github, but has yet to percolate through to the release versions.

After change
vim /etc/apt/sources.list.d/unipi.list as you wrote, everything works

#deb https://files.unipi.technology/debian stretch main
deb https://repo.unipi.technology/debian stretch main

thanks for support

Hi @sindyk,
no, your PLC will work as expected. These messages are not valid and they are meant to be valid in next version of MervisIDE, where the licensing of the PLC will be mandatory. You can ignore those for now.

Best regards,
Martin

@lefrank01 thank you for sharing your tips. I have also had this reported once or twice and on each occasion starting from a clean install of Raspbian, installing CODESYS for Raspberry Pi and then running the script that ships with CODESYS for UniPi has resolved users problems.

@Vesa-Kauppinen
Glad to hear it works now!

EVOK 2.0 should work fine UniPi 1.1, but obviously much of the extra hardware functionality which Neuron has will be missing.

The UniPi 1.1 also has an EEPROM, it's just in a slightly different format. The reason that the installation needs to know which hardware you have is that we need to install certain different libraries to get the hardware to work correctly. Unfortunately this cannot be done automatically, as the EEPROM is not loaded during the installation yet.

@tomas_knot

Hi,

Thanks, I think now it's clear.

Right after boot I tried multiple times same command, with only few seconds in between;

Results are somehow changing;

pi@f:~ $ sudo grep M503 /sys/bus/i2c/devices/1-0057/eeprom Binary file /sys/bus/i2c/devices/1-0057/eeprom matches pi@f:~ $ sudo grep M503 /sys/bus/i2c/devices/1-0057/eeprom Binary file /sys/bus/i2c/devices/1-0057/eeprom matches pi@f:~ $ sudo grep M503 /sys/bus/i2c/devices/1-0057/eeprom Binary file /sys/bus/i2c/devices/1-0057/eeprom matches pi@f:~ $ sudo grep M503 /sys/bus/i2c/devices/1-0057/eeprom pi@f:~ $ sudo grep M503 /sys/bus/i2c/devices/1-0057/eeprom pi@f:~ $ sudo grep M503 /sys/bus/i2c/devices/1-0057/eeprom

See how last 3 lines there is suddenly no eeprom available ? So something fishy about i2c bus perhaps.

I then went on to think about connecting oscilloscope to see what's going on and what we have done so far. When thinking about where to connect it, it hit me - we have an external 7" Pi LCD connected to Raspberry Pi Display connector and it has those 2 extra SDA and SCL pins... Could they be reason for this... They are there for A and B model Pi's that don't have these integrated to display-cable and as this is version 3 Pi, they should not be connected as those are routed via display cable. So I disconnected them and after boot so far it has performed flawlessly!

Below are results of the same "test" as above, this time results are all predictable and ok, every time there is an eeprom device on the bus.

pi@f:~ $ sudo grep M503 /sys/bus/i2c/devices/1-0057/eeprom Binary file /sys/bus/i2c/devices/1-0057/eeprom matches pi@f:~ $ sudo grep M503 /sys/bus/i2c/devices/1-0057/eeprom Binary file /sys/bus/i2c/devices/1-0057/eeprom matches pi@f:~ $ sudo grep M503 /sys/bus/i2c/devices/1-0057/eeprom Binary file /sys/bus/i2c/devices/1-0057/eeprom matches

So, this was my error, not thinking that connection of LCD could anyway be in part of this... Sorry about that.

But many thanks for your excellent support! For me at least, I think the issue is now solved (fingers crossed...).

I'm surprised the

check_for_errors(response)

line doesn't catch it. Either way thanks for the fix, we'll include it in the next commit!

Happy to hear that it works for you now.

ok I will try to use the /home/pi/ folder.

@Martin-Kudláček it works, but you have to attach using the "Use deploy parameters" as described a few posts above

Yes, that seems about right. It's designed to allow multiple RJ45 connectors to share the same 1Wire bus.

We've been toying with the idea of making a Modbus-based active 1Wire hub, but it would be considerably more limited in which devices it can support.

Helo @jos0,
the name "holding register" doesn't mean the value is stored in the non-volatile memory. This is just a type of the data store which comes from the Modbus naming convention, which means it can be read and written into, as oppose to the Input register, which can be only read.

You can save the current value of the counter register with the saving of the current values to internal flash. This save can be initiated by e.g. setting the coil named "Save current configuration and use on startup" which has to be called on the appropriate group.

We do not recommend to do it very often as this will corrupt the internal memory. Try solving the problem in the program instead.

Best regards,
Martin

Thanks for your help!

I have to execute the command in sudo for the LEDs, but it works fine! So, I will execute a chmod command after boot time.

@martin-kudláček Hi, I'm also trying to use 1.7beta, can you send me new MervisIDE 2.1.3 link, please?

@tomas_hora, thank you.

I have been reading more about your products and I found out that EVOK provides websockets. I was thinking that I would write a script which would process MQTT messages from a dongle and deliver them to Mervis using websocket and the other way around. Would that work? It would replace the Node-red which you suggested.

Thank you for your help, Martin.