Domoticz

CopyCatz wrote:The block stucture has changed from 873 onwards. You have to rebuild your event blocks.

I had done this , but when a have more then 1 'and' block it happens again It shows my blocks in a weird structure like my example above.

I just tested in 898 with multiple and's, no problems here, are you on a recent version?

CopyCatz wrote:I just tested in 898 with multiple and's, no problems here, are you on a recent version?

I have version 1.887 , latest to download from download page. And I have a email when a new version is online.
But I think it's the time block. Whenever there's a time block in , it screwed by saving.

spiderrob wrote:I can confirm that dim level works in blocky with my lightwave dimmers. There is a small discrepancy in that if I set the dim level to 10%, when the event triggers the light shows up as 6% in the Domoticz dashboard. It's the same throughout the % range but it doesn't matter.

Ok - further testing with dim set levels. They work on their own but do not work with .... for x minutes. ?? Would love to have this available.

That's a bit more complex.. For the "for x minutes" action I just look at the reciprocal activitiy, e.g. when you say "On" for 10 minutes, the device is set to on, the system determines the opposite is off and schedules that in 10. Reciprocal activity for Set Level 50, what should that be.. off?

CopyCatz wrote:That's a bit more complex.. For the "for x minutes" action I just look at the reciprocal activitiy, e.g. when you say "On" for 10 minutes, the device is set to on, the system determines the opposite is off and schedules that in 10. Reciprocal activity for Set Level 50, what should that be.. off?

I would say yes. What ever the dim level, the actual underlying function is always on, so the reciprocal should be off. Be great to see this implemented.

If the user wants to get sophisticated with reversing dim levels then they should be set as separate events.

Thanks again.

capman wrote:

CopyCatz wrote:I just tested in 898 with multiple and's, no problems here, are you on a recent version?

I have version 1.887 , latest to download from download page. And I have a email when a new version is online.
But I think it's the time block. Whenever there's a time block in , it screwed by saving.

Problem solved with version 899.

Thanks

v900: Implemented: Set Level and Random for dimmers, events triggers only after previous one completes, "Set Level" text in blockly shortened, other devices status and measurements now passed to lua as name instead of id, small fixes.

If you set an action for x minutes or random within x minutes the same event will not trigger unless the previous one completed. Otherwise a random 30 setter could theoretically launch 29 more times until the first one completes. I also added an extra 5 seconds to the final minute count, otherwise you could build a time script saying" if time > 10.00 set lamp is on for 1 minute. Which would fire every minute, essentially switching the light on permanently. The 5 seconds past the minute will at least switch the lamp off for 55 seconds to show what's wrong.

Thanks for adding the panic-state. I created an event to turn a group of lights ON when the smokedetector is in panic-state. I'm loving the events!

I'm still thinking about what "turn on for x minutes" should be based on. Should it be:

- Turn on then off (the opposite/reciprocal action) after x minutes
- Find out the current state, turn on, then go to previous state after x minutes.

Option 2 could mean that if a lamp was already on, and gets set for 1 minute, essentially nothing changes...

CopyCatz wrote:I'm still thinking about what "turn on for x minutes" should be based on. Should it be:

- Turn on then off (the opposite/reciprocal action) after x minutes
- Find out the current state, turn on, then go to previous state after x minutes.

Option 2 could mean that if a lamp was already on, and gets set for 1 minute, essentially nothing changes...

Is this in relation to the dimmers and set level also ? I think option 2 is a great idea and really covers all options. That means you could go from a light that is on 100% to an event requiring 50% dimmed (Eg Cinema mode), and then returning to on 100% after 90 minutes.

Or, you could start with a light that is off - An event triggers a 25% dimmed level for x minutes and then returns to off again. I'm wanting to utilize this for a night time event. Eg If the children's night lights are off and the landing PIR is triggered, I want the landing light to come on at only 25% for 2 minutes so they can find their way to the toilet!

Hi CopyCatz,

Is there a way to filter out the "Unknown" (un)named devices?

Hmm not sure where those are coming from... The list should only display devices in use.. Did you delete a bunch?

Fixed in 923.

CopyCatz wrote:Fixed in 923.

Great, thanx

Is it possible the security status isn't monitored yet? I don't see it in the logs, and I can't make an event based on it, it doesn't fire.

- v1.928: Implemented: if.. else if.. in Blockly, new database structure to accommodate, fixed security status in blockly.

It is now possible to use if.. else if.. statements, but only at the top level. This can be used to group event logic that deals with the same device or device group. Add "else if" blocks to the structure by clicking the + sign.

I've been playing a little with the event system and it seems really easy.
However I am running into some issue's.

I'm trying to create a scenario when my doorbell is pressed a certain light turns on for 0.1 minutes if that light would be off.
If that light would be on the light turns off when the doorbell is pressed for 0.1 minutes (I also tried 1 whole minute to see if the 0.1 would not function).

When I try to use blocky it looks like I need the "group on" command, but when I check the current states it says the doorbell is already in the "group on" state.
This to me seems to be in conflict with my blocky string and as expected nothing happens. What command should I use for the doorbell?

Funny that 0.1 minute works, I did not anticipate that, please test. I think a kaku doorbell is always "Chime", on or off, it sends Chime again when pressed. Chime status was not in the status dropdown yet, I just added it in 932.

Edit: I think your if statements are incorrect.. you pasted "OFF and Deurbell..." in the opening where you should only drop the off. Start off with 2 blocks:

woonkamer lamp = off
Deurbel = group on (must be Chime later)

grab an and block and drop in the other 2.

That way the logic will be if ((woonkamer lamp = off) and (Deurbel = Chime)). yours reads: if(woonkamer lamp=(Off and and (Deurbel = Chime))

Thank you for your explanation for the statements. Your method seems more logical when I think about it.
So I changed the blocks and for testing purposes I also changed the time to a full minute.
Now when I press the doorbell the light turns on and of randomly.
I think this has something to do with the status of the doorbell always stating "group on".
I had to restart domoticz as the light still turned on and off after I unchecked the event.

Kinda funny though.
It seems I still need to learn allot about the events.

Is it the way the doorbell sends the command? Within domoticz I am able to use the doorbell as a trigger to take a snapshot with the ip-camera when pressed. Is this different from the blocky method?