Hello @raedhammad,
this looks like a HW issue. Are you sure you didn't draw more than 20mA from the analog output? That would certainly destroy it.

Best regards,
Martin Kudlacek

Hi @juntiedt,
there is a M103 with 8 relays.

Hello @origami,
the UniPi 1.1 doesn't need any firmware. To use the newest set of tools, do full update & upgrade of the operating system.

Best regards,
Martin

Hi Martijn,

I am also trying to read analog and digital ports on unipi to collect sensor data from few sensors. I was also just wondering if we can do it in the same way like we do it on raspberry pi using a python script. I can see that even you wanted to do something like that. I have also gone through evok api but they seem to be specific models. I dont think using that we can directly read analog and digital I/Os on unipi. Can you please suggest any ideas if you were successful doing that?

Thanks,
Jitu

Mockrát děkuji za odpověď.

Ouu.. thank you....
my fault... Problem was with a connector... I mixed RJ11 connector with RJ45...
Anyway.. Thank you :)

Hello @PR-Reger,

Generally speaking that is always the safer approach, if possible.

Regards,
Tomas

@francoisd You can do it by hand or use .csv to import Modbus device definition - https://kb.mervis.info/doku.php/en:mervis-ide:30-communication-protocols:30-modbus?s[]=modbus&s[]=csv

I've created the device definition for you, so you can simply import it by right clicink on the modbus TCP channel and select Import device definition.

The .csv file should contain:

StationNumber,Name,Element,Count,Function,Writable,StType,ByteOrder,K,Q,X1,Y1,X2,Y2 1,PWM_prescale,1018,1,HoldingRegister,1,Int,12,,,,,, 1,PWM_cycle,1019,1,HoldingRegister,1,Int,12,,,,,,

dear @raedhammad, people should definitely know what they are going to face, but blaming our solution without knowing what went wrong...

As stated previously, please continue in the email communication so we have just one point where to talk so we can discuss all your issues there. We can then past the conversation here if other might want to read through.

@jiriletak Dobrý den, LED světla obecně se chovají kvůli integrovanému zroji tak, že špičkový proud při sepnutí může přesahova ti třicetinásobek proudu při běžném odběru. Rozhodně nedoporučujeme tedy takovétho zátěže připojovat přímo na RO našich jenotek a raději to řešit pomocí spínacích prvků k tomu určených. Naše RO jsou míněna jen jako ovládací, pro další silové spínací prvky.

Hi Martin
Thank you for quick response.

Jiri

Hi @arolli,
yes, you can start all 4 relays at the same time.

Martin

Hello @knebb,
the current official way is to use Raspbian Stretch, then add our repository and install evok from it. Use the instructions on https://github.com/UniPiTechnology/evok.

Regards,
Martin

Hi @dalibor ,
that's odd, it should definitely work. Can you share the project with me on support@unipi.technology?

Thanks,
Martin

Hi @stevenbrs,

The DOs are NPN type (open collector), check the documentation for proper wiring. Everything is OK with your HW and SW, do not worry.

@ikiiwii Wifi Configuration is not yet implemented in Mervis, so you would have to configure the wifi client in linux using ssh. Then you will setup SSCP communication between those 2 Neurons.

Ok; took me quite some time, but I just did manage to read out the sensor values.

Leaving this here as future reference; the involved PIR sensor was the Jablotron JS-20 Largo. A small schematic was provided with the sensor out of the box, but the key find for me was that the sensor outputs also need to be wired up to the 12V power source; see adapted schematic and pictures.

Thanks a lot for the schematics, since they really made it possible for me to reverse-engineer the setup.

Hi @mohamed-dounnani,
the addressing is as follows:

/dev/extcomm/0/... <- All serial ports (0 = RS485 1.1, 1 = RS485 2.1)
/dev/extcomm/1/... <- Serial ports of Group 1 (0 = RS485 1.1)
/dev/extcomm/2/... <- Serial ports of Group 2 (0 = RS485 2.1)

You can reveal the structure by listing the directory:

unipi@L503-sn101:~ $ ls -l /dev/extcomm/* /dev/extcomm/0: total 0 lrwxrwxrwx 1 root root 12 Aug 31 09:51 0 -> ../../ttyNS0 lrwxrwxrwx 1 root root 12 Aug 31 09:51 1 -> ../../ttyNS1 /dev/extcomm/1: total 0 lrwxrwxrwx 1 root root 12 Aug 31 09:51 0 -> ../../ttyNS0 /dev/extcomm/2: total 0 lrwxrwxrwx 1 root root 12 Aug 31 09:51 0 -> ../../ttyNS1

Martin

@mohamed-dounnani,
your calculations are in order. With the tests we did above, I am afraid you received a PLC with wrong calibration data. The calibration is a way how to ensure that when you set a desired voltage through Modbus registers, it will in fact set the correct voltage on the terminal connectors. The calibration process is one of many throughout the assembly of the unit. The calibration is done on our testbenches and it means you have to send the unit back to us. We sincerely do apologize for this.

Please send me (kudlacek@unipi.technology) your number of order for this PLC and I will get back to you with further information.

Thank you very much,
Martin