Device "Regulator - Level Control" issue

Moderators: grovkillen, Stuntteam, TD-er

Post Reply
Message
Author
User avatar
M*I*B
Normal user
Posts: 379
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Device "Regulator - Level Control" issue

#1 Post by M*I*B » 20 Jan 2023, 11:12

Good morning everyone

After I scrapped the PowerMeter project because it simply didn't work with the given devices/modules with ESP32, I took a closer look at the above-mentioned module.

First problem:
As stated at https://espeasy.readthedocs.io/en/lates ... /P021.html, one should use...

Code: Select all

config,task,<taskname>,SetLevel,<value|calculation>
... can set the appropriate value.
The controller device is task 4 for me and is simply called "Regler". So if I type ...

Code: Select all

config,4,Regler,SetLevel,20
on the command line (Tools/Command), I get an OK, but the value is not changed.

That simply doesn't work for me, probably because I didn't understand something correctly...

However, the query with ...

Code: Select all

[<task name>#GetLevel]
... works without any problems.


I wouldn't have noticed that if I hadn't tried to add a day/night control afterwards.
Maybe it would also be better with regard to the flash write cycles to drill out the module a bit so that you can store two or three values, which you can switch as needed...
DLzG
Micha


TD-er
Core team member
Posts: 9221
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Device "Regulator - Level Control" issue

#3 Post by TD-er » 20 Jan 2023, 11:45

Yep, the syntax of that level plugin is a bit non-standard... So we decided to allow more plugins to follow it to make it more standard ;)

Just kidding... but we did however borrow the idea of getting more values out of a task than would be accessible as taskvalues.
For example the GPS plugin now also gives access to this via "virtual" taskvalue names.
I'm thinking about whether or not we should also use this rather funky "config" command for other plugins to set values.
We do have a number of commands specific for a plugin, but there are some generic settings each task has.
I'm thinking about adding those to this config command as well.
I know Ton already started adding some of the generic settings to be configured via this command, but not sure if that's already merged, nor which settings he was working on to set via this config command.

User avatar
M*I*B
Normal user
Posts: 379
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Device "Regulator - Level Control" issue

#4 Post by M*I*B » 20 Jan 2023, 12:35

chromo23 wrote: 20 Jan 2023, 11:21

Code: Select all

config,task,Regler,SetLevel,20
banging-head-stressed.gif
banging-head-stressed.gif (88.74 KiB) Viewed 3924 times
I have try so many combinations... except this :roll:
TD-er wrote: 20 Jan 2023, 11:45 Yep, the syntax of that level plugin is a bit non-standard... So we decided to allow more plugins to follow it to make it more standard
...
I know Ton already started adding some of the generic settings to be configured via this command,
Good to know. That gives hope. Obviously we think alike on these things...
You should still think about whether it would not be good to provide non-volatile memory here in general and detached or also module-specifically. The beginner will not use this. But if you go a little further, you will eventually reach the point where you want to make your construct safe from power failures.
In my opinion, if the corresponding warning regarding write cycles is stored in the documentation, this is enough to make the user pay attention to it.
DLzG
Micha

TD-er
Core team member
Posts: 9221
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Device "Regulator - Level Control" issue

#5 Post by TD-er » 20 Jan 2023, 13:33

Not sure it will stop users from doing so.
I have seen at least once, that a user called this command to reset the write counter every minute from the rules as it was annoying.

User avatar
M*I*B
Normal user
Posts: 379
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Device "Regulator - Level Control" issue

#6 Post by M*I*B » 20 Jan 2023, 15:01

TD-er wrote: 20 Jan 2023, 13:33 Not sure it will stop users from doing so.
I have seen at least once, that a user called this command to reset the write counter every minute from the rules as it was annoying.
🤣🤣🤣🤣🤣

Really?!
DLzG
Micha

User avatar
Ath
Normal user
Posts: 3918
Joined: 10 Jun 2018, 12:06
Location: NL

Re: Device "Regulator - Level Control" issue

#7 Post by Ath » 20 Jan 2023, 15:18

M*I*B wrote: 20 Jan 2023, 15:01
TD-er wrote: 20 Jan 2023, 13:33 Not sure it will stop users from doing so.
I have seen at least once, that a user called this command to reset the write counter every minute from the rules as it was annoying.
🤣🤣🤣🤣🤣

Really?!
https://www.brainyquote.com/quotes/albe ... ein_100015 ;)
/Ton (PayPal.me)

User avatar
M*I*B
Normal user
Posts: 379
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Device "Regulator - Level Control" issue

#8 Post by M*I*B » 20 Jan 2023, 15:35

Einstein is right... no more questions 😎😜

But back to the roots...
I am of the opinion that it should be up to each user how often he wants to write to the flash. The user can usually read and write and is responsible for what he does there. And if he ignores that, it will soon cost him a few dollars for a new ESP; his problem.
I'm a big opponent of patronizing of all kinds, also in terms of software. If a piece of software like a schoolmaster wants to tell me what to do or what not to do, I always and without exception perceive this as an infringement of my personal rights and as an insinuation that I am a DAU (stupidest possible user). For me that's the quickest way to switch on my red lamp...
First of all on this topic...

When it comes to the controller module, I will now switch from day to night mode at certain times by changing the value at least twice a day with "config,task,Regler,SetLevel,[value]".
In this context, I had considered an extension to other values, between which you can then simply switch with one command, without having to write to the flash again each time.
So let's say three values (and hysteresis) are provided: value 1 for day, value 2 for night, value 3 for special purposes.
One of the values can be set as POD (PowerOnDefault) or simply POD is ever the 1st value.
With a command, for example with a construct like "config,task,Regler,ActiveLevel,<1|2|3>, one of the values is then set as the active value, e.g. according to the time of day.

And while we're at it:
The "config,task, ..." part is always the same. Couldn't you simplify it and replace it with "TaskConf,..." or something like that?
DLzG
Micha

User avatar
M*I*B
Normal user
Posts: 379
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Device "Regulator - Level Control" issue

#9 Post by M*I*B » 20 Jan 2023, 18:40

Ok, run into a problem while initialize my stuff...

I have to check after cold start if the actual time is between Time1 and Time2, i.e. between 05:30 and 22:00.
This times are hold in a dummy, hours and minutes separated (due a dummy can't hold a time). So ...
Dh = 5, Dm = 30, Nh = 22, Nm = 0
This values are written into the dummy after system#Boot. The Problem is that a "0" isn't a "00" then.
The idea was to see it as string and couple hours and minutes, but that doesn't work due the missing zero...

Is there an elegant way to check that? I haven't much chars left for the rule...

Ohh wait!

Can I use a construct like this?

Code: Select all

%systime% > ([Zeiten#Dh]:[Zeiten#Dm]:00) and %systime% < ([Zeiten#Nh]:[Zeiten#Nm]:00)
... this one don't work, also not if I write '[Zeiten#Nh]:[Zeiten#Nm]:00' or {'[Zeiten#Nh]:[Zeiten#Nm]:00'} ...
help.gif
help.gif (141.73 KiB) Viewed 3833 times
Last edited by M*I*B on 20 Jan 2023, 19:17, edited 1 time in total.
DLzG
Micha

User avatar
Ath
Normal user
Posts: 3918
Joined: 10 Jun 2018, 12:06
Location: NL

Re: Device "Regulator - Level Control" issue

#10 Post by Ath » 20 Jan 2023, 19:15

You could use:

Code: Select all

%systime% > ([Zeiten#Dh#D2]:[Zeiten#Dm#D2]) and %systime% < ([Zeiten#Nh#D2]:[Zeiten#Nm#D2])
But you can also use %syshour% and %sysmin% numeric variables to compare to:

Code: Select all

if %syshour% > [Zeiten#Dh] and %sysmin% >= [Zeiten#Dm]
...
endif
/Ton (PayPal.me)

User avatar
M*I*B
Normal user
Posts: 379
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Device "Regulator - Level Control" issue

#11 Post by M*I*B » 20 Jan 2023, 19:31

Ohh, thank you very much ... I try this right now after this...

Just a Q:
%systime% is in format hh:mm:ss so do it also work if I don't offer the fake-seconds?


They have to be the fake-seconds. It don't work without it; I have test that.
I now use this:

Code: Select all

on Time#Initialized do
	// Set Level of Regulator after cold start
	if [Regler#GetLevel] != [Sollwert#D] and [Regler#GetLevel] != [Sollwert#N] and %systime% > ([Zeiten#Dh#D2]:[Zeiten#Dm#D2]:00) and %systime% < ([Zeiten#Nh#D2]:[Zeiten#Nm#D2]:00)
		config,task,Regler,SetLevel,[Sollwert#D]
	else
		config,task,Regler,SetLevel,[Sollwert#N]
	endif
endon
Based on:
Bild_2023-01-20_201016911.png
Bild_2023-01-20_201016911.png (6.31 KiB) Viewed 3813 times
But this don't work as expected. They set the temp for the night and not for the day. If I write it down with real values it looks like that (the systime- part):

Code: Select all

... and 20:12:08 > 05:30:00 and 20:12:08 < 22:00:00
So systime is greater than Zeiten#Dx and also less than Zeiten#Nx but the IF-THEN-ELSE runt the ELSE- Part
Last edited by M*I*B on 20 Jan 2023, 20:15, edited 2 times in total.
DLzG
Micha

User avatar
Ath
Normal user
Posts: 3918
Joined: 10 Jun 2018, 12:06
Location: NL

Re: Device "Regulator - Level Control" issue

#12 Post by Ath » 20 Jan 2023, 20:11

When not provided, the seconds will default to 00
/Ton (PayPal.me)

User avatar
M*I*B
Normal user
Posts: 379
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Device "Regulator - Level Control" issue

#13 Post by M*I*B » 20 Jan 2023, 20:36

Ok, I have simplify the rule- snipped like that:

Code: Select all

on Time#Initialized do
	if [Regler#GetLevel] = 0 and %systime% > ([Zeiten#Dh#D2]:[Zeiten#Dm#D2]:00) and %systime% < ([Zeiten#Nh#D2]:[Zeiten#Nm#D2]:00)
		config,task,Regler,SetLevel,[Sollwert#D]
	else
		config,task,Regler,SetLevel,[Sollwert#N]
	endif
endon
So the Level is at 0.00 (1st cold start). If I'm right all in the IF are true: Level is 0, systime is greater then 05:30 and less then 22:00 ...
... but the Level is set to Sollwert#N(ight) instead of Sollwert#D(ay)

Simplified more like this:

Code: Select all

on Time#Initialized do
	if %systime% > ([Zeiten#Dh#D2]:[Zeiten#Dm#D2]:00) and %systime% < ([Zeiten#Nh#D2]:[Zeiten#Nm#D2]:00)
		config,task,Regler,SetLevel,[Sollwert#D]
	else
		config,task,Regler,SetLevel,[Sollwert#N]
	endif
endon
Same result! Also the ELSE is executed. Since only the time comparison remains as a source of error; it does not work that way...

More simplified (kill the fake-seconds)... Same result...
DLzG
Micha

User avatar
Ath
Normal user
Posts: 3918
Joined: 10 Jun 2018, 12:06
Location: NL

Re: Device "Regulator - Level Control" issue

#14 Post by Ath » 20 Jan 2023, 20:45

Removing the round braces ( and ) from your IF statement should fix that (just been testing your rule)
/Ton (PayPal.me)

User avatar
M*I*B
Normal user
Posts: 379
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Device "Regulator - Level Control" issue

#15 Post by M*I*B » 20 Jan 2023, 20:52

Bild_2023-01-20_204854706.png
Bild_2023-01-20_204854706.png (3.15 KiB) Viewed 3801 times
YEP! That was the fault all the time. Now I can build up the IF step by step to my former comparison

Thanx a lot!
I was just relying on you, as a star programmer, to have presented it correctly and that the mistake was mine. I would have only come to the brackets just before despair :D
DLzG
Micha

User avatar
Ath
Normal user
Posts: 3918
Joined: 10 Jun 2018, 12:06
Location: NL

Re: Device "Regulator - Level Control" issue

#16 Post by Ath » 20 Jan 2023, 21:00

If concocted this:

Code: Select all

  if %systime% > [Zeiten#Dh#D2]:[Zeiten#Dm#D2]:00 and %systime% < [Zeiten#Nh#D2]:[Zeiten#Nm#D2]:00
    if [Regler#GetLevel] != [Sollwert#D]
      logentry "SetLevel Day"
      config,task,Regler,SetLevel,[Sollwert#D]
    else
      logentry "nop Day"
    endif
  else
    if [Regler#GetLevel] != [Sollwert#N]
      logentry "SetLevel Night"
      config,task,Regler,SetLevel,[Sollwert#N]
    else
      logentry "nop Night"
    endif
  endif
Changed Nh to 21:

Code: Select all

2209776 : Info   : EVENT: Clock#Time=Fri,21:02
2209840 : Info   : ACT  : logentry "SetLevel Night"
2209842 : Info   : SetLevel Night
2209844 : Info   : ACT  : config,task,Regler,SetLevel,15
NB: I have this code in my on Clock#Time=all,**:** do rule ;)
/Ton (PayPal.me)

User avatar
M*I*B
Normal user
Posts: 379
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Device "Regulator - Level Control" issue

#17 Post by M*I*B » 20 Jan 2023, 21:05

Ahhh, that I must remember how do you debug this type of trouble... Thanx for teaching me that!

Ok, now it works perfect! That will be my standard regulator for SONOFF S20 now...

Full code with comments are here. To use it you have to kill most comments due of the maximum of 2048 chars for rules...
If you find some improvements, feel free to kick my ass :D

Code: Select all

on System#Boot do
//	LoopTimerSet,1,2
	// Prefill all Data after cold start
	Let,1,0 // Status Button
	Let,2,1 // Status Automatic
	TaskValueSet,8,1,21.0	// Daytime- temperature
	TaskValueSet,8,2,18.5	// Nighttime- temperature
	TaskValueSet,9,1,05	// Time to start Day/hour
	TaskValueSet,9,2,30	// Time to start Day/minute
	TaskValueSet,9,3,22	// Time to start Night/hour
	TaskValueSet,9,4,00	// Time to start Night/minute
endon

on Time#Initialized do
	// Set Level of Regulator after cold start
	if [Regler#GetLevel] = 0 and %systime% > [Zeiten#Dh#D2]:[Zeiten#Dm#D2] and %systime% < [Zeiten#Nh#D2]:[Zeiten#Nm#D2]
		config,task,Regler,SetLevel,[Sollwert#D]
	else
		config,task,Regler,SetLevel,[Sollwert#N]
	endif
endon

on Regler#SET do
	// Regler ACTIVE && KEY ON || Regler ACTIVE && Regler ON
	if [Regler#settings.enabled] = 1 and [Regler#SET] = 1 or [Regler#settings.enabled] = 1 and %v1% = 1
		gpio,12,1
	// Regler ACTIVE && KEY OFF && Regler OFF
	elseif [Regler#settings.enabled] = 1 and [Regler#SET] = 0 and %v1% = 0
		gpio,12,0
	endif

	// Regler PASSIVE? Let the LED flash (GPIO 13, same as WLAN)
	if [Regler#settings.enabled] = 0
		longpulse_ms,13,1,300,100,5
	else
		longpulse_ms,13,1,0
	endif
endon

// Time to switch to over day temperature
on Clock#Time=All,[Zeiten#Dh]:[Zeiten#Dm]
	config,task,Regler,SetLevel,[Sollwert#D]
endon

// Time to switch to over night temperature
on Clock#Time=All,[Zeiten#Nh]:[Zeiten#Nm]
	config,task,Regler,SetLevel,[Sollwert#N]
endon

// Create own Events to check Key and LC at once
// LongPress: Toggle the regulator (OFF/AUTOMATIC)
// ShortPress: Toggle between AUTO and ON (ON 
on Taste#BTN do
	asyncevent,KeyCheck=%eventvalue1%
	LET,1,%eventvalue1%
endon

on Regler#SET do
	asyncevent,KeyCheck=%eventvalue1%
	LET,2,%eventvalue1%
endon

// Ask Keypress and LC
on KeyCheck do
// Regler ACTIVE && KEY Longpress? Regler PASSIVE, RLY OFF
	if [Regler#settings.enabled] = 1 and %v1% > 9 
		gpio,12,0
		TaskDisable,4
 // Regler PASSIVE and KEY Longpress? Regler ACTIVE, RLY OFF
	elseif [Regler#settings.enabled] = 0 and %v1% > 9
		gpio,12,0
		TaskEnable,4
	endif
endon

// Base system: SONOff S20, 4pin 3,5mm Plug, !! Wire from PE to GND !!
// 10k resistor inside Plug, not in device. GND=GND, Ring 1 = TX, Ring 2 = RX, TIP = +Ub
// DEVICES
//  1 - Switch input - Switch 		- "Taste#BTN" 	- GPIO0
//  2 - Switch input - Switch 		- "Relais#RLY" 	- GPIO12
//  5 - Regulator - Level Control	- "Regler#SET"	- Task11
//  8 - Generic - Dummy Device		- "Sollwert#D	- °C Day tt.t
//  8 							- "Sollwert#N	- °C Night
//  9 - Generic - Dummy Device		- "Zeiten#Dh"	- Day Hour
//  9							- "Zeiten#Dm"	- Day Minutes
//  9							- "Zeiten#Nh"	- Night Hour
//  9							- "Zeiten#Nm"	- Night Minutes
// 11 - Environment - DS18b20		- "Sensor#TMP"	- either ... 
// 12 - Environment - DHT11/12...	- "Sensor#TMP"	- ... or
// 12 							- "Sensor#HUM"	-
DLzG
Micha

User avatar
Ath
Normal user
Posts: 3918
Joined: 10 Jun 2018, 12:06
Location: NL

Re: Device "Regulator - Level Control" issue

#18 Post by Ath » 20 Jan 2023, 21:07

I have this in my on System#Boot do rule:

Code: Select all

  TaskValueSet,Zeiten,Dh,5
  TaskValueSet,Zeiten,Dm,30
  TaskValueSet,Zeiten,Nh,21
  TaskValueSet,Zeiten,Nm,0
  TaskValueSet,Sollwert,D,20
  TaskValueSet,Sollwert,N,15
Much more readable, and task-number independent 8-)
/Ton (PayPal.me)

User avatar
M*I*B
Normal user
Posts: 379
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Device "Regulator - Level Control" issue

#19 Post by M*I*B » 20 Jan 2023, 21:09

... you are right ... let's see if the space are enough to do that ...
DLzG
Micha

User avatar
Ath
Normal user
Posts: 3918
Joined: 10 Jun 2018, 12:06
Location: NL

Re: Device "Regulator - Level Control" issue

#20 Post by Ath » 20 Jan 2023, 21:14

M*I*B wrote: 20 Jan 2023, 21:05 due of the maximum of 2048 chars for rules...
That limit has been lifted a long time ago, but to reduce the size of the rules files, improving rules processing speed, the warning is left in the system :lol:
/Ton (PayPal.me)

User avatar
M*I*B
Normal user
Posts: 379
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Device "Regulator - Level Control" issue

#21 Post by M*I*B » 20 Jan 2023, 21:15

... ohhh fuck :roll:
Nice that you tell me that now :lol: Better late then never :roll:
DLzG
Micha

TD-er
Core team member
Posts: 9221
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Device "Regulator - Level Control" issue

#22 Post by TD-er » 20 Jan 2023, 21:37

M*I*B wrote: 20 Jan 2023, 15:35 [...]
I'm a big opponent of patronizing of all kinds, also in terms of software. If a piece of software like a schoolmaster wants to tell me what to do or what not to do, I always and without exception perceive this as an infringement of my personal rights and as an insinuation that I am a DAU (stupidest possible user). For me that's the quickest way to switch on my red lamp...
[...]
Well, we're not trying to prevent you from doing stupid things. As a matter of fact, we even tell you how to do it by literally handing you the command :)
But what would not be nice is if a node suddenly goes rogue and save-crash-reboot-save-crash.... causing it to die in a matter of hours without leaving any trace of what went wrong.
Not only does that cause a lot of frustration among users, but also will cost us a lot of time to look for some issue in the code which is an user error.
Thus this limit is there to protect the user, prevent wasting time and building up frustration.

And if you want to unlock this, I literally gave you the receipe to do so :)
You don't even have to compile a custum build for it.

Just keep in mind, I am probably even more allergic to being told what not to do and that things can't be done.
After all, if I were someone like that, I wouldn't be working on ESPEasy, but rather buying something off the shelve with all kinds of vendor-lock-in as a bonus.

User avatar
M*I*B
Normal user
Posts: 379
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Device "Regulator - Level Control" issue

#23 Post by M*I*B » 20 Jan 2023, 21:46

... you're certainly right, but I didn't mean that as an attack against you.
I've learned, especially in the past few years, that you can't get people to do the right thing with a lot of cajoling and tons of facts; It just cost some their lives because they were of the opinion that the state would be right, including my mother; there is no point in investing time in such people.
So I'm pretty rigorous in that direction now. If someone doesn't want to listen, they should just leave it alone...

Do you see what I'm getting at?


BTW:
TD-er wrote: 20 Jan 2023, 21:37 ... causing it to die in a matter of hours without leaving any trace of what went wrong.
Not only does that cause a lot of frustration among users, but also will cost us a lot of time to look for some issue in the code which is an user error. ... bonus.
That's why I'm using NP++ for the rules. Somewhere here I have grab the language file and change the file extensions in the XML so that I can use esp, rule and txt for it to automatic identify the file; in the XML is also a little mistake: File extensions are to be noted without a dot. ".ext" is wrong, "ext" is right. You also can define more then on like "esp rule txt"
DLzG
Micha

User avatar
M*I*B
Normal user
Posts: 379
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Device "Regulator - Level Control" issue

#24 Post by M*I*B » 23 Jan 2023, 22:22

Ok, more trouble...

Code: Select all

Dh = 05
Dm = 30
Nh = 22
Nm = 0

Code: Select all

on Clock#Time=All,[Zeiten#Dh#D2]:[Zeiten#Dm#D2] do
	config,task,Regler,SetLevel,[Sollwert#D]
	TaskValueSet,Sollwert,IS,[Sollwert#D]
endon

on Clock#Time=All,[Zeiten#Nh#D2]:[Zeiten#Nm#D2] do
	config,task,Regler,SetLevel,[Sollwert#N]
	TaskValueSet,Sollwert,IS,[Sollwert#N]
endon
This parts don't work, neither with #D2 nor without. The value will not be set in "Regler" nor in "Sollwet#IS"

What I'm doing wrong? I don't see/find it ^^
DLzG
Micha

TD-er
Core team member
Posts: 9221
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Device "Regulator - Level Control" issue

#25 Post by TD-er » 23 Jan 2023, 22:33

Code: Select all

on Clock#Time=All,[Zeiten#Nh#D2]:[Zeiten#Nm#D2] do
This won't work, as was already reported a few weeks ago by another user.
I have not found the time yet to look at this.

What you can do, is to every minute check those variables against %syshour% and %sysmin%.

User avatar
M*I*B
Normal user
Posts: 379
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Device "Regulator - Level Control" issue

#26 Post by M*I*B » 23 Jan 2023, 22:37

... ok then I have not to wonder 8-) Not my fault *jabbadabbadoooo* :lol:

Ok, I will do so as you say for now. If you find time to fix that, I would be very happy if you would communicate this here ...
DLzG
Micha

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest