Ahh I was assuming you are using Neuron; with the UniPi 1.1 you need to rename the inputs and outputs in the "evok.conf" configuration file; using aliases with the UniPi 1.1 is not supported as the various subdevices are fundamentally different devices. Whereas for Neuron they are, well, subdevices, which are communicated with via Modbus handles. And it is these handles which are renamed with the alias.

I can have a look if we can implement the aliases for UniPi 1.1 as well, but as of right now it's not possible. We should remove the alias-setting option for UniPi 1.1 from the web inteface.

As for the instructions, they will indeed get you the latest Master version.

I think this is caused by internal state caching, as the state update takes some time to propagate and be read back. This is an issue we constantly face with Mervis, but in practice is true for all asynchronous communication with the device. Is it possible that the physical real state is at odds with what you get back from EVOK?

If that is indeed what is happening, then unfortunately there isn't much we could do, besides using a write-back cache for relays. Which potentially could cause desynchronisation issues further down the line.

Dobrý den,

bohužel phillipsnick/unipi-evok není oficiální verze EVOKu, takže chování nemůžeme zaručit. Nicméně dotaz na DI opravdu vrátí stav daného DI; změny jsou počítané jen ve WebSocket kodu, a nikde jinde nejsou použité.

Hi @juntiedt!
That looks great, and does perform very well.

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.

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.

Glad you got it working!

This should now be fixed in our latest opensource image and EVOK release as well.

You can change the

access_log /var/log/evok.access.log;

line near the top of your /etc/evok-nginx.conf file to

access_log off;

This should take care of it. You can also pipe it to /dev/null or create some sort of a log rotation scheme using CRON instead.

Does the web interface function correctly? It is based on the same websocket listening process and so it should exhibit the same behavior.

I've tested your code (copy-paste into a python file called wstest.py) on the latest UniPi opensource distribution (essentially just debian with kernel drivers, which only improve UART functionality as far as EVOK is concerned) and it functions as expected, with the following output:

Value: 0 Device: input Circuit: 1_01 Value: 0 Device: input Circuit: 1_02 Value: 0 Device: input Circuit: 1_03 Value: 0 Device: input Circuit: 1_04 Value: 0 Device: relay Circuit: 1_01 Value: 1 Device: relay Circuit: 1_02 Value: 1 Device: relay Circuit: 1_03 Value: 0 Device: relay Circuit: 1_04 Value: 0.00772160933422 Device: ai Circuit: 1_01 Value: 2.29423873804 Device: ao Circuit: 1_01 [{"counter_mode": "Enabled", "counter_modes": ["Enabled", "Disabled"], "glob_dev_id": 1, "dev": "input", "ds_modes": ["Simple", "Inverted", "Toggle"], "modes": ["Simple", "DirectSwitch"], "ds_mode": "Simple", "debounce": 50, "counter": 0, "value": 0, "mode": "DirectSwitch", "circuit": "1_01"}, {"counter_modes": ["Enabled", "Disabled"], "glob_dev_id": 1, "modes": ["Simple", "DirectSwitch"], "value": 0, "circuit": "1_02", "debounce": 50, "counter": 0, "counter_mode": "Enabled", "dev": "input", "mode": "Simple"}, {"counter_modes": ["Enabled", "Disabled"], "glob_dev_id": 1, "modes": ["Simple", "DirectSwitch"], "value": 0, "circuit": "1_03", "debounce": 50, "counter": 0, "counter_mode": "Enabled", "dev": "input", "mode": "Simple"}, {"counter_modes": ["Enabled", "Disabled"], "glob_dev_id": 1, "modes": ["Simple", "DirectSwitch"], "value": 0, "circuit": "1_04", "debounce": 50, "counter": 0, "counter_mode": "Enabled", "dev": "input", "mode": "Simple"}, {"glob_dev_id": 1, "modes": ["Simple", "PWM"], "value": 0, "circuit": "1_01", "pending": false, "relay_type": "digital", "dev": "relay", "mode": "Simple"}, {"glob_dev_id": 1, "modes": ["Simple", "PWM"], "value": 1, "circuit": "1_02", "pending": false, "relay_type": "digital", "dev": "relay", "mode": "Simple"}, {"glob_dev_id": 1, "modes": ["Simple", "PWM"], "value": 1, "circuit": "1_03", "pending": false, "relay_type": "digital", "dev": "relay", "mode": "Simple"}, {"glob_dev_id": 1, "modes": ["Simple", "PWM"], "value": 0, "circuit": "1_04", "pending": false, "relay_type": "digital", "dev": "relay", "mode": "Simple"}, {"glob_dev_id": 1, "unit": "V", "value": 0.007721609334224814, "circuit": "1_01", "range_modes": ["10.0"], "modes": ["Voltage", "Current"], "range": "10.0", "dev": "ai", "mode": "Voltage"}, {"modes": ["Voltage", "Current", "Resistance"], "value": 2.2942387380392786, "glob_dev_id": 1, "dev": "ao", "circuit": "1_01", "unit": "V", "mode": "Voltage"}] Value: 0 Device: wd Circuit: 1_01 [{"circuit": "1_01", "value": 0, "glob_dev_id": 1, "dev": "wd", "timeout": 6000, "was_wd_reset": 0, "nv_save": 0}] Value: 0 Device: wd Circuit: 1_01 [{"circuit": "1_01", "value": 0, "glob_dev_id": 1, "dev": "wd", "timeout": 6000, "was_wd_reset": 0, "nv_save": 0}] Value: 0 Device: wd Circuit: 1_01 [{"circuit": "1_01", "value": 0, "glob_dev_id": 1, "dev": "wd", "timeout": 6000, "was_wd_reset": 0, "nv_save": 0}] Value: 0.00511440622282 Device: ai Circuit: 1_01 Value: 0 Device: wd Circuit: 1_01 [{"glob_dev_id": 1, "unit": "V", "value": 0.005114406222816542, "circuit": "1_01", "range_modes": ["10.0"], "modes": ["Voltage", "Current"], "range": "10.0", "dev": "ai", "mode": "Voltage"}, {"circuit": "1_01", "value": 0, "glob_dev_id": 1, "dev": "wd", "timeout": 6000, "was_wd_reset": 0, "nv_save": 0}] Value: 0.00772160933422 Device: ai Circuit: 1_01 [{"glob_dev_id": 1, "unit": "V", "value": 0.007721609334224814, "circuit": "1_01", "range_modes": ["10.0"], "modes": ["Voltage", "Current"], "range": "10.0", "dev": "ai", "mode": "Voltage"}] Value: 0.00511440622282 Device: ai Circuit: 1_01 Value: 0 Device: wd Circuit: 1_01 [{"glob_dev_id": 1, "unit": "V", "value": 0.005114406222816542, "circuit": "1_01", "range_modes": ["10.0"], "modes": ["Voltage", "Current"], "range": "10.0", "dev": "ai", "mode": "Voltage"}, {"circuit": "1_01", "value": 0, "glob_dev_id": 1, "dev": "wd", "timeout": 6000, "was_wd_reset": 0, "nv_save": 0}]

It would be helpful if you could post the output of "print obj" and "print message", inserted after the first line of the on_message function, as well as which distribution of EVOK you are using and which version of python.

e: Added the output of the "all" which I've omitted at first.

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.

It's the number of milliseconds for which a signal has to hold; there is a good explanation of it here: https://www.kernel.org/doc/Documentation/gpio/driver.txt (section titled
"GPIOs with debounce support"). The idea being to filter out harmonics which occur due to electro-mechanical interference.

Jessie has a different netconf stack from Stretch, so the AP will not work there - and there is a rather large all-capitals warning during the installation to not use anything else than clean Raspbian Stretch.

Regardless it should work now, we'll have a quick look at what could go wrong.

Hi Tomas,

reinstalled evok -master today but unfortunately the filter function with "temp" or "sensor" did not work for ds2438.

@juntiedt OK, thanks for the additional info. We'll take a look at it.

Ok thx !

@Vesa-Kauppinen This is a bit more complicated than it seems. First of all, Evok cannot guarantee any time of physical response. Secondly, there is a lot of overhead with the HTTP encapsulation. All this together with available CPU processing power at the moment of the request (actual load of CPU by other applications) can lead to a various time of reaction to the request.

From what we have tried it can take about 150ms to switch the relay when the command is called from the same RPi using curl.

If you need faster responses, you can always use the default Modbus TCP where you will get to around 10ms response time.

hi thomas,

thx for answering.

i think that maybe a subsequent softwareupdate was the cause.

but i just started over with a clean noobs/raspbian, updated all packages and installed evok and then openhab and in the moment all works fine and at the same time.

i hope the problem will not arise again and i can happily start playing with openhab and evok.
next time i will have a spare sd lying around so i can backup the erroneous to analyse the causes.

wbr,tja...

(edit)
PS: nah i didnt install pigpio. must have been some other cause.

Thank you for your fast Response.

I think the version number 2.4 was a misunderstanding. I was talking about Config version 2.4. my fault.

I have solved this problem by installing a new OS Raspbian Stretch 2017-11-29. And afterword’s installed all my needed Software.

Now everything works as designed

Thank you

Christoph

@juntiedt the gateway is a simple Modbus device. You map the 1wire sensors to the Modbus registers using the utility for Windows and then read them using any Modbus AnyLanugage library. Everything is described in the documentation.

@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