forum

I have found a bug, in my setup its very critical, i have to say that right now its a show stopper.

Let me explain what i have done so far and the function that i need.

I have a complicated setup with many rules that decide if a light should be on or off, based on time, light, buttons, windows open/close and so on.

The calculations for this is made right now in another program, i might move all over to zway but it will take much time to make modules for all calculations, but that is not the problem right now.

The issue i have right now is the function that the light should be Off when a window is open and On when window is closed, I am using a Fibaro door/window sensor for this. Here is the current flow:

Fibaro status --> Module send status to external program --> calculates if light should be on/off --> Send update to DummyDevice via /ZAutomation/api/v1/devices/ --> DummyDevice is included in If/else module and turn the light on/off.

This is working almost as it should, if i change the state on the Fibaro to fast then on or off commands get lost in space. I have debugged this and the reason is that if you send several commands in a row through /ZAutomation/api/v1/devices/ commands get lost, it does not queue the requests.

You could reproduce the issue very easy, you don't have to send commands that quick, try with on / wait 1 sek / off / wait 1 second...and commands are most likely lost.

So the question is, is there a better communication protocol that i could use instead of /ZAutomation/api/v1/ or is that api going to be rewritten to handle multiply requests?

I am doing half of this with thermostatic radiator valves. I do shut the valve off with a LogicalRule on a window open event regardless the present setting of the valve because that setting doesn't matter. (A second similar rule could switch it back on. I haven't done this yet because of the poor support for StellaZ mode switching)

The point with using logical rules is that one must try to keep them as simple as possible, and not to be afraid to create quite a few.

I have to say that they are giving us a great possibility with the user module functions, so we could solve almost everything with that. But there is some basic things that just must work, and my observation about the lost of commands is one thing that must be solved, and also the other question how to get metric from a device, but maybe there is a way, we just have to figure out how.

I am using a now discontinued application named Beyond Measure that has a very powerful logical/rule engine, I am adding a lot of data to that application from sensors all over my house, so its a must to have a working way back in with data to zway.

Isaksson wrote:I have to say that they are giving us a great possibility with the user module functions, so we could solve almost everything with that.

LogicalRule is a "standard" function distributed with the system. Using that is different from writing a userModule to achieve a dedicated tasks, like controlling Sonos devices or as I have done for example with my solar logging modules.

But there is some basic things that just must work, and my observation about the lost of commands is one thing that must be solved, and also the other question how to get metric from a device, but maybe there is a way, we just have to figure out how.

I do agree with your point that metrics, other than level should also be retrievable with the ZAutomation API. Presently I do use the OpenRemoteHelpers function metric for that. But that only works for Z-Wave devices.

I am using a now discontinued application named Beyond Measure that has a very powerful logical/rule engine, I am adding a lot of data to that application from sensors all over my house, so its a must to have a working way back in with data to zway.

I assume you can't capture those sensors with Z-Way? Just to better understand your case, could you give some idea of how your most complex rule looks like?

So by logicalRule you do not mean the Local App logical Rule? i mean that is exactly the kind of module that we could write.

Iam using some old nexa buttons and also alote of arduino that is using MQTT for data transfer so at the moment i cant do that only with Z-Way, but i see no problem to use Beyond Measure, just need a good way back with data to Z-Way.

I do mean the local app LogicalRule.

pz1 wrote:I do mean the local app LogicalRule.

Thats good so that I not have missed a great rule engine in Z-Way.

Isaksson wrote:Thats good so that I not have missed a great rule engine in Z-Way.

I don't know how great it is. I also don't know what algorithm they implemented. (Rete and derivatives are the basis for OpenRemote Drools) I know PoltoS is not too keen to add more complexity to it.

@pz1 Indeed, I'm Unix man - less is more pipe different modules and make each module clear and simple.

Complex modules are acceptable only for very typical and common tasks.

But community is free to do own extremely complex overkilling module. We keep freedom and community involvement as the most important key of our Z-Way controller.

Of course, a module should not be more complex then it has to be

But i think that you all agree that it should be possible to send two commands once a second through the api?
I hope that you PoltoS take a look at this or maybe send this to the person that could check this issue.