Blockly and lightsensor

[LazyLizzard]

Hi!

I have a problem with my lightsensor and blockly. Can you please help me and see if I've done something wrong?

I have a "lightsensor" on 1-wire. It is a sensor that reports a voltage depending on the light. I want to use this sensor (Ljussensor Ute NV) to turn a dummy switch (Tända) on and off depending on the voltage. On a value below 200 I want it to be on, and over 200 I want it to be off. I'm going to have som more parameters in it later aswell, but for now I just want this simple thing to work. I have made a blockly like in the picture, but it wont work. When the value is above 200 there is no problem, the switch is off. But when the value drops below 200 it keeps going on and off at the same time. Have I done something wrong?

Maby a simple mistake by me, or is it something wrong in domoticz? I'm currently running v3.6595 built from source.

Any ideas?

//LazyLizzard

[kalinkamaen]

I cant see anythin g wrong. But try to set it up like this so you do not have the same number for on and off:



You can also try 199 if thats better.

[Toulon7559]

Possible 2 reasons for the frequent switching.

1) Why did you include Tända=Off respectively Tända=Off in the IF-statements?
2) Checking in both Blockies just at the 200-level may cause a frequent switching, due to a dynamically fluctuating light-input.

Possibly around the '200'-level your 2 Blockies interact due to switching delays interfering with the check in the IF-lines.
Probably you intend to check whether it is necessary to switch, but the 'rude' method also works, of simply ordering a switch without check beforehand.
As improvement for 1) suggest to try in the first Blocky the simpler IF-statement
IF Ljussensor ute NV < 200
And in the second Blocky
IF Ljussensor ute NV > 200
To solve the dynamic aspect under 2) you can somewhat 'smooth' the new check by including a hysteresis like:
IF Ljussensor ute NV < 190
IF Ljussensor ute NV > 210
The practical thresholdvalues have to be found emperically.

[LazyLizzard]

1) I like to have the Tända Off/On in the IF-statements for the blocky to check if it need to turn it on or off. But It's absolutley not needed for the function. I removed it for now just to get the main funcion of turning on and off to work.

2) It will absolutley cause frequent switching when the value in around 200, because it fluctuates. But the thing is that it keep turning on and off all the time even when the value have dropped. Like now for example the value is 56, but still keeps turning off and then on again.

I tried your examples, but unfortunatley it doesn't make any difference . Maby it just is some kind of a bug?

Thanks a lot for trying to help though!!

[tozzke]

the "problem" without that check, is that without them, the if statements keep triggering which asks quite a lot of Domoticz (check the log)

[LazyLizzard]

Exactly tozzke! Thats also a reason to why I want to have the check.

[PeGe]

Maybe a very silly question, but could it possibly be that the light source you turn on with "Tända" also affects (i.e. is seen by) your light sensor?

- It's too dark, so: "Tända" -> On
- Now it's too bright, so: "Tända" -> Off
- Damn, it turned dark again... "Tända" -> On

... and so on ... I think you get the point...

I suppose you have already eliminated such elementary root causes, but even the simple things can sometimes be easily overseen!

Furthermore; Avoiding unnecessary CPU and memory load, by checking the current state before acting, is always "good programming practice"!

/P-G

[LazyLizzard]

Thats not a silly question Sometimes you make really simple mistakes

Although that is not the problem this time. The sensor is outside where its not affected by anything else but the light outside.

Now when testning it also only controlls the dummy switch. Later the dummy will controll lighting inside.

[Toulon7559]

What happens if you include a time-delay in the switching for a lightlevel < 200, by means of the middel block shown below?
It is a 'cosmetic' treatment, but with such delay you can suppress undue switching due to fluctuations of the light-input.

Blocky time-elements

Knipsel170212.JPG (18.81 KiB) Viewed 2828 times

Sometimes it helps to apply a separate, auxiliary signal (a socalled 'semaphore' or 'flag'), instead of directly taking the result of the IF-statement using the signal-input. Reason: you clearly separate into slow and fast loops to avoid undesired, dynamic interaction, and the real switching is only performed at the conclusion of the decision process.
You have a flagman, which after his own looking & thinking, by flagging generally guides the traffic (= your dimmer) ......

Possible (simplest) example layout for your case applying Blocky-components, incl. help of a delay:
IF level <200, DO "Flag = True for 5 minutes"
IF Flag = true, DO Dimmer = ON

Background:
level < 200 = raise the flag, level > 200 = do nothing, and wait until the flag drops
For realization of such layout you will have to add a userdefined variable Flag.
That addition may anyway be useful, because such variable is stored outside the script, and can be reused at the start of the script.

[PeGe]

One thing that puzzles me when viewing your switch history listing, is the fact that both the ON and OFF transitions occur at the very same second. That "should" be impossible, according to the logic you have defined.

The script will only run once per second, and when the first 'If' expression evaluates as TRUE, it should never even attempt to evaluate the 'Else if' during the same excution cycle. Consequently, it would be practically impossible for the script to take both of the actions at the exact same time.

You wouldn't happen to have another (similar) copy of that script activated simultaneously? When testing new stuff myself, I often save multiple versions of my work, so it wouldn't be a situation totally unheard of...

/P-G

[tozzke]

One thing that puzzles me when viewing your switch history listing, is the fact that both the ON and OFF transitions occur at the very same second. That "should" be impossible, according to the logic you have defined.

The script will only run once per second, and when the first 'If' expression evaluates as TRUE, it should never even attempt to evaluate[/b] the 'Else if' [/b]during the same excution cycle. Consequently, it would be practically impossible for the script to take both of the actions at the exact same time.

You wouldn't happen to have another (similar) copy of that script activated simultaneously? When testing new stuff myself, I often save multiple versions of my work, so it wouldn't be a situation totally unheard of...

/P-G

You might think that but it does @ Domoticz

[PeGe]

You might think that but it does @ Domoticz

Seriously?

Now, I don't intend to hijack this thread, but I would truly consider that behavior to be a serious bug, as "ESLE" would have completely lost its meaning!

In my every day life, I'd always use "else if" statements in such a sequence that the most probable condition to evaluate as TRUE comes on top, continuing down depending on "what the odds are". If you have a sequence of let's say 20 "else if" sections and you'd get a hit already in the second statement, a system SHOULD NEVER be bothered with processing the remaining ones. After all, that's the whole basic idea with "else if" vs just multiple consecutive "if"s.

Disappointing...

/P-G

[jensc]

Interesting point. Bug, yes?

[Toulon7559]

This thread raises the question:
why not an ELSE or ELSIF in Blocky?
To make unambiguous decisions after a check.