Hello,
the config file is utterly wrong. If you don't use any extension, you need to comment out all the lines of the [EXTENSION_1] block, not just the [EXTENSION_1] line. The syntax of this config file is based on the INI file. That means the active lines of the config where assigned to the [NEURON_1] block, thus resulting in unexpectable behaviour.

;[EXTENSION_1] global_id = 2 ; Mandatory, REQUIRED TO BE UNIQUE device_name = xM103 ; Mandatory modbus_uart_port = /dev/extcomm/0/0 ; Mandatory ;neuron_uart_circuit = 1_01 ; Optional, allows associating extensions wi$ ;allow_register_access = True ; Optional, False default, is mandatory with third-p$ ;address = 1 ; Optional, 1 default ;scan_frequency = 10 ; Optional, 10 default ;scan_enabled = True ; Optional, True default ; Note that the following settings will be inherited by other devices sharing the same port, i.e. /d$ baud_rate = 38400 ; Optional, NEEDS UNIPI IMAGE TO WOR$ parity = N ; Optional, NEEDS UNIPI IMAG$ stop_bits = 1 ; Optional, NEEDS UNIPI IMAGE TO WOR$

@martin-kudláček Ano zmínka v manuálu o tom byla, já sám sem si říkal, že by to mohlo být prohozené, ale nikde jsem nenašel, jak má to pořádí být zaspané v Mervisu :-(
A pokud jde o SolarEdge, nemyslím si že máte pravdu.
Modbus TCP je označená měnič, jako server - na straně 7, kde se píše, že server čeká dvě minuty na odezvu klienta a pak se vypne.
U 485 je možnost dvou konektorů, kdy je jeden master a druhý sleve. Já budu mít na 485 pověšený elměr od SolarEdge, tak bych chtěl využít Modbus TCP k vyčítání hodnot z měniče do Axona.

According to the manual: https://files.unipi.technology/index.php/s/zTmrEbQEvifNd6W?path=%2FProducts%2FNeuron%2FDocumentation#pdfviewer

chapter 2.2.1 LED diodedescription

and later MWD description. It means you do not communicate with the devices. Which is also notable that there is no output when you run the server by hand.

Hi @r3sist,
the:

IF bPumpOn THEN hw.$Neuron M203_RO_2.06_w$:= TRUE; ELSE hw.$Neuron M203_RO_2.06_w$:= FALSE; END_IF;

is exactly the same as this:

hw.$Neuron M203_RO_2.06_w$:= bPumpOn;

If there is no syntactic error, which would be detected upon MervisIDE Build, then there is error in the program itself. Try uploading it here or sending it to [email protected]. Please, include a VERY detailed description of the real process, not the itself program. It will help find the real issue.

Hi @martin-kudláček,

I am not sure to undersand:

It was stable during > 2 months but now, I can reproduce the issue systematically with USB port 1 (after a few hours of operation), but not when connecting the same hardware to USB port 2.

Kind regards,

Pascal

@gabrielsoudry Hello Gabriel,

We plan to release the new Bookworm-compatible EVOK, along with new OS images, by the end of February. However, if we encounter bugs during testing, this may extend until the end of March.

ZR

tag @martin_triska

hi Tomas,

sorry for my recent post!
I have solved the problem!
I had to delete the cache of my chrom browser and now it works!

have a nice Weekend

@zorro_66 if you double click on the error in the result table, it will usually show you where the issue is... Or just read what it says.

0_1497967748550_Screenshot_5.png

Thank you

@Giamba I see that you are posting C source. I have found python in /usr/bin but I do not find any gcc or make anywhere. There is also no java installed. I am not an RPi user (I use nV embedded systems) so am not familiar with Jessie ... do I need to install these programming runtimes and environments? Do you know what size SD card I need to get to this environment?

Apologies, I had taken time off for personal reasons for the last two days. I will be here over the next two weeks every day.

sorry for the websocket issue. Its now running.

the only thing left is the unipi_eprom problem in the boot process of Raspbian

@juntiedt said in sedtronic light intensity sensor:

Hi Tomas,

after reinstalling evok everything is ok!
Many thanks for your professional support.
have alook at my trainings unipi control panel 188.194.138.174
temp devices get updated every minute and the other devices uses evok websocket events.

Hannes

That looks really excellent! Glad you got it working well now.

Apologies for the issues with EVOK.
Kind Regards
Tomas

@majorcsa
Unfortunately not, the updates have broken our driver three times within the past year, and so even if it is technically easy to do with a simple build script, it's not feasible for the process to be automated in such a way.

The kernel updates by their nature change the entire API around which our driver is built, often changing things like includes, data structures, macros, function signatures etc. The process is somehow formalised by how the linking process for Linux drivers works, namely the use of a symbol table, but again the table itself changes quite a lot. Not all changes will break the module, but many have.

This is the same reason why Raspbian itself only updates to one version in ~20, and is many updates behind the latest, as it always needs to be tested (and updated) for compatibility.

Dobrý den @beny44,
zatím bohužel ne.

The problem has been solved by flashing the latest firmware.

Hello @lukas009,

we plan to release Debian 13 based systems, but we do not have any ETA.

@tomasknot
Aha, thanks, that is very helpful. In that case,
Could you please share a picture of the required bypass on the Unipi board?

@Andmo
That looks about right - could you describe in more detail the problems you are having?

It's quite hard to tell from the screenshot.

Hello @stoeffel,

If this happens, you do not need to reboot the whole neuron, just reset the 1Wire bus using Modbus or OW_off variable in case of Mervis.

Let us know what you find out.