Hi @achilleas-kotsis , @Martin-Kudláček ,

has it been fixed in the master branch? I am facing to the same problem.

Thank you

@martin-kudláček yes, correct.

@tja regarding Openhab Modbus binding...not easy to setup but fully functional.

PM

@martin-kudláček I use Evok and Openhab HTTP binding in order to querying data from Unipi and sending commands. Below is an example of response times from Openhab log in case of sending request for 2 relays.

2018-09-26 22:00:00.202 [ome.event.ItemCommandEvent] - Item 'UnipiRelay1' received command OFF
2018-09-26 22:00:00.243 [ome.event.ItemCommandEvent] - Item 'UnipiRelay5' received command OFF
2018-09-26 22:00:00.354 [vent.ItemStateChangedEvent] - UnipiRelay1 changed from ON to OFF
2018-09-26 22:00:00.368 [vent.ItemStateChangedEvent] - UnipiRelay5 changed from ON to OFF

So the response is within 1-2 tenths of second. The same with querying of digital outputs.

There are also many additional services running on Unipi at the same moment like Apache2, DynDNS agent, Raspbian desktop, VNC server, SSH server...

@martin-kudláček I have several implementations of Openhab on Unipi and it works pretty fast regardless of Java (Zulu or Oracle) and number of bindings. I use simultaneously i.e.HTTP, Zwave, Astro, MAX! and other bindings. CPU is at 2-5%. In next few weeks we will play with Modbus binding in order to manage some air-conditioners. Now we are just waiting for delivery of Modbus serial gateway. So I will let you know then.

Hi Tomas,

there is something wrong with "time". It cannot be the number of second since epoch. Look at conversion back to date what results I get when trying to convert "time" back to human readable format

petr@raspberrypi2:~# date
Čt čen 16 08:57:40 CEST 2016
petr@raspberrypi2:~# date –date='@1187716472'
Út srp 21 19:14:32 CEST 2007
petr@raspberrypi2:~# date
Čt čen 16 08:58:03 CEST 2016
petr@raspberrypi2:~# date --date='@1202551130'
So úno 9 10:58:50 CET 2008

Where could be a problem? Is it a bug in Evok? If not what really represents "time"?

Thank you

Resolved but not fully. The situation now is following. I have two devices connected to DI_2 and D_3. They show the same value as expected as they measure the same power line. Nevertheles DI_1 increasing the value as well even without connected device. Its value is aproximately a half of the DI_2 and DI_3. I made no changes on debounce time. Possibly bug in evok?

Yes, I'll try over the weekend.

No, I haven't. But it is exactly my plan. I will let you know the result.

Frequency of blinking depends on consuption of course. There are LEDs directly on the wattmeter. They blink simultaneously with LEDs on Unipi. Therefore Unipi is getting pulses well. Normaly the consumption is 180-200Wh. Wattmeters provide 2000 pulses per kWh. The lenght of one puls is 80ms according to manufacturer. The frequency of blinking is around 5-6 seconds. It corresponds well to consumption I think. Unfortunately only DI_1 shows adequate number of pulses. DI_2 provides approx.1.5 less pulses. The debounce time is default. It means 0. If I change the debounce parameter to whatever, the counter remains still 0. Is the debounce time in seconds or miliseconds?

I have two wattmeters exactly the same type. Both are reading consumption on the same power line. There is no electrical appliance between them. Wattmeters show the same consuption in total. I can see two LEDs on Unipi board blinking in the same frequency. One by one. Therefore I expect to get the same counter value from both devices. Unfortunatelly it differs very significantly. One of them count 26000 pulses. The second one 17000. Do you have any explanation or suggestion what to change in order to get the expected result?

BTW what is the difference between falling and rising counter mode? Both are increasing when getting pulses.