administrators

@mdturnerphys Unfortunately no. But for example, you will need to create a Server channel on one side (A) select port different than 502 and map your variables to holding/input registers/coils so you can read and write to them from the other (B) side. You can map the variables to Units for example 0-10 (if you need more, just map it as you wish). On the other side just create a custom device on Modbus TCP channel (B), set the IP address and port of the (A). Then on (B) create a read group with starting register 0 and 10 number of registers and map the variables from (A) to data points (create datapoint by right click, assign read group...). Check F1 help of Mervis for 'Modbus' there is a nice explanation. You can also check eg. the Inepro example project from our downloads section.

@bsc101 So I guess you used the Windows firmware update tool as @salorob. There are definitely a bugfixes from version 5.9 with some new functionality as well. You have the tutorial above, so you can update it, if you find out you need it.

Hi @martijn-hemeryck,
thanks for such comprehensive information!

The direct switch indeed is for special cases and I can understand, why you want to deal with this in the software. The limited number of outputs of L303 is one of the many reasons. But that leaves you with emulating momentary switch in the software, for now.

The reason why we picked polling instead of events is that even on the SPI level we use Modbus protocol. Therefor it is less resource consuming to "reshare" the HW values over our ModbusTCP server. The polling of the underlying HW via SPI is not what has the highest impact on the responsivness, because it happens in sub-milisecond intervals. The real slow down happens in applications which use the data - the software PLCs, like Home Assistant. If you are looking for fast and deterministic PLC, you have to look into HW PLCs like Mitsubishi, Omron, Siemens, B&R,... But then you will lose the flexibility.

Replacing the ModbusTCP server with MQTT client would be technically possible, but we don't have any ambitions in this area (yet). But we can support you with neccessary information about the SPI communication we use, if you decide to do it on your own.

Connecting 24V LED strip to DO should definitely work, if you are sure you will not draw more then 750mA. You can check the presence of 24V on the DO turned ON with multimeter. If there is another voltage or no voltage at all, the DO is burned.

DALI. This is a chapter on its own. And since you're not the only one asking about it, I have good news for you. Check this thread: https://forum.unipi.technology/topic/691/evok-dali-support-apis/4
Writing a DALI-MQTT bridge is certainly doable and with python-dali it should be a piece of cake for you, as a seasoned python dev. But the DALI itself is bit complicated, especially in autodetection of unaddressed devices.

Regards,
Martin

Hi @roberts_lando,
the support of DALI in the EVOK is as described by @tomas_hora and right now we don't have any specific time schedule on extending the support. Due to the fact, that we use most of our manpower on finalisation of UniPi Axon's these days, it is highly possible, that we won't be able to work on it this year. BUT!:-)

We do have a complete HW support + low level API for sending and receiving DALI packets. It is still bit unofficial, but you can:

1. Send and receive DALI packets interfacing our ModbusTCP server
2. Use python-dali library together with our UniPi DALI connector

For next week, we are planning to unveil our very own Knowledge Base, where this will be thoroughly documented.

If you implemented a solution in Node-RED, you probably have some sort of interface with connector to the DALI backend - to be able to switch backends without disrupting the frontend functionality. I can imagine you can write a backend to our ModbusTCP registers map or to python-dali library. How does that sound to you?

Regards,
Martin

@jelle You have to enable internal pull-up resistor for the GPIOs and set them as inputs

@joe160781 Discussed in email communication

@mdturnerphys Hopefully the next release will be published within a few weeks in the meantime, you can create Modbus TCP connection between those two units

Hi @Boy-Lenssen,
I have created a tutorial, how to flash the firmware via SSH: https://forum.unipi.technology/topic/693/multiple-xs50-on-a-l513-rs485/20

Let me know, if you are OK with this. We certainly can update the firmware for you via Teamviewer as promised above.

Thanks,
Martin

Ok, the issue is definitely with the extension firmware 5.6. The current version is 5.18 and for some reason, both of you received extension units with the old firmware... We do apologize for this, if it is even possible.

The @salorob was able to flash the firmware by his own via our Windows application tool. Unfortunately, the tool is also long time waiting for the update, so the firmware version in this tool is only 5.9, instead of 5.18.

So the official hacker's tutorial is:

1. SSH into your controller, the user "pi", the password (if not changed) is "raspberry". If your image is Raspbian, you need to install additional packages:

pi@raspberrypi:~ $ sudo bash
root@raspberrypi:/home/pi# echo "deb https://files.unipi.technology/debian stretch main" > /etc/apt/sources.list.d/unipi.list
root@raspberrypi:/home/pi# wget -O - https://files.unipi.technology/debian/unipi_pub.gpg | apt-key add
root@raspberrypi:/home/pi# apt update
root@raspberrypi:/home/pi# apt install -y neuron-firmware neuron-modbus-tools

2. Connect the extension to the controller over RS485. If you have multiple extensions, connect only one at a time. Right now, all of them thinks they have address 15, so you need to avoid collisions.

3. Confirm, you have a connection to extension

root@L503-sn101:/home/pi# /opt/neuron-bin/fwserial -p /dev/extcomm/0/0 
Boardset:     5 E-14Ro_P-11DiR485              (v1.0)
Baseboard:    2 E-14Ro                         (v1.0)
Firmware: v5.6
Modbus timeout set

4. Flash the firmware

root@L503-sn101:/opt/fw# /opt/neuron-bin/fwserial -p /dev/extcomm/0/0 -PR
Boardset:     5 E-14Ro_P-11DiR485              (v1.0)
Baseboard:    2 E-14Ro                         (v1.0)
Firmware: v5.6
Modbus timeout set
Programming page 00 ...Finished programming chunk 0, ret: 64 err: 0
Finished programming chunk 1, ret: 64 err: 0
Finished programming chunk 2, ret: 64 err: 0
Finished programming chunk 3, ret: 64 err: 0
Finished programming chunk 4, ret: 64 err: 0
Finished programming chunk 5, ret: 64 err: 0
Finished programming chunk 6, ret: 64 err: 0
Finished programming chunk 7, ret: 64 err: 0
Page written OK.

Programming page 01 ...Finished programming chunk 0, ret: 64 err: 0
..........

5. Verify the firmware. Since the flashed firmware now accepts address set by DIP switches, you need to specify the address in the parameter -u. My extension has address 3

root@L503-sn101:/opt/fw# /opt/neuron-bin/fwserial -p /dev/extcomm/0/0 -u 3
Boardset:     5 E-14Ro_P-11DiR485              (v1.0)
Baseboard:    2 E-14Ro                         (v1.0)
Firmware: v5.18
Modbus timeout set

6. Repeat the process for all of the extensions

Let me know, how it worked. If you don't want to flash the firmware yourself, let me know and we can arrange some remote session with you.

Thanks,
Martin

@bsc101 The way to check and update the firmware is fairly easy - just connect the extension via RS485 to the controller, ssh into the controller and run a program. I will write down a tutorial how to do so. We just want to be extra sure, that this problem is tied down to the extension's firmware. I do apologize for this incovenience.