v3.1.21 in beta ; minor updates, one question

[sjenkins]

Couple extras that I would rather add to the beta before we mess with production:  

For those who use generic / dimmer which persistence was aded in the previous beta I added visibility to the onLevel(OL) in the AC or eisy-ui.  The question is would you rather OL is "dynamic" where it changes to last set or "static" where it starts default at 100 but when is set to something less it stays there until re-set.  Very much a preference thing.  If we want to mirror Insteon we use the former, but many devices use the latter.  Does not affect device or scene commands.  FEEDBACK please.

Added a Notice when someone forgets to tick the little box for authorisation to write to ISY.  Matters for temperature & garage nodes if they are configured to write to ISY variables.  I have seen this on a regular basis for those new to the node.

The rest are in the logs but should be invisible to the user.  Other than debug, or the above choice in dimmer/generic, I am thinking that the development cycle can slow down now.

 

3.1.21
DONE generic/dimmer to model dimmer ST & OL
DONE name & address check using poly interface
DONE consistent use of poly versus polyglot
DONE fix nagging error check in main()
DONE controller discover refactor
DONE add notice for ISY authorized error (was only in logs)

3.1.20
DONE fix controller ST "status" on at start, off at stop / delete, "control" still heartbeat
DONE garage send CMDs, motor, motion, obstruction ; get naming consistent
DONE standardize startup sequence
DONE rewrite checkParams, Discovery
DONE add NumberOfNodes
DONE switch/generic/dimmer/temp(R/C): nodes use polyglot persistence, delete old db files
DONE swtich cmd TOGGLE add
DONE consolidate temp, tempC, tempRC into one module
DONE temp variable writing now with shortPoll (only upon change, considers precision)
DONE refactor function naming
DONE refactor garage, fix persistence, sse client
DONE backfeed garage improvements to switch(done), generic(done), temperature()

 

[hart2hart]

I prefer Insteon definition for OL so it stays consistent with other behaviors.

[Diesel]

It could be helpful to add two optional params (global or per-node) that default to current behavior so nothing changes for existing users, but power users have the flexibility to fine tune:

MIN_ON = 10  → floor used when OL is 0 or DIM reaches 0 so the next DON isn’t zero.

STEP_PCT = 3 → brighten/dim step size.

 

 

 

[sjenkins]

13 hours ago, Diesel said:

It could be helpful to add two optional params (global or per-node) that default to current behavior so nothing changes for existing users, but power users have the flexibility to fine tune:

 

MIN_ON = 10  → floor used when OL is 0 or DIM reaches 0 so the next DON isn’t zero.

 

STEP_PCT = 3 → brighten/dim step size.

 

 

 

For everyone's info, currently 10 is already being used as the floor for onLevel and 2 is the increment/decrement for brighten/dim.

if we want this I would likely do this per node as dimmer/generic is the only Virtual node using these parameters.

@hart2hart , I tend to agree with you on the Insteon definition, I did this method after added the persistence and before realising I should look at how my other many switches work.

 @Diesel, what do you think, static onlevel or dynamic(last on) onlevel?

.....others?

 

Edited yesterday at 11:36 AM by sjenkins

[Diesel]

Thanks for 3.1.21. Appreciate the OL visibility. For OL behaviour, I think a default Dynamic (Insteon-like) makes the most sense. If you feel inclined, maybe a per-node OL_MODE that can be set to Static for folks who prefer a fixed preset? 

[sjenkins]

So the proposal:

 

Dimmer/generic by-the-node:

default = Insteon = Static

- set the onLevel(OL) manually or programatically  5-100

- not changed by DON/DOF/DFON/DFOF/BRT/DIM

- modelling behaviour of Insteon

 

optional = Dynamic

- onLevel CAN be set manually or pragmatically 5-100

- changed to current level with BRT/DIM, will not go below 5 or above 100

- changed to last level with DOF, DFOF

- basically a "last on" persistence for status

 

Will need to add GV0 to be flag for the static(default)/dynamic choice.

 

defaults, range:

ST = 0, 0-100

OL = 100, 5-100

GV0 = Static, Static/Dynamic

This work?

 

[Diesel]

Looks solid!

Just a bit confused on the static/dynamic terminology change.

In the first post you referred to Insteon-like as dynamic, but now default = Insteon = Static?

Calling the default “Insteon = Static” may confuse some (many think of “resume last” as “Insteon-like”).

In any case; 

GV0: Mode with editor choices Preset (Static) / Last On (Dynamic).

Keeps your proposed behavior; avoids confusion over what is “Insteon-like” 

Per-node mode with a default and an optional dynamic mode is perfect. Proposed ranges make sense.

Static (default)

OL (5–100) is a preset the user/programs set.

DON/DOF/DFON/DFOF/BRT/DIM do not change OL.

Matches lots of non-Insteon devices’ “preset OL” behavior.

Dynamic (optional)

BRT/DIM update OL to the current level (clamped 5–100).

DOF/DFOF set ST→0 and set OL to the last (pre-off) level (“last on”).

OL can still be set manually or programmatically (clamped 5–100).

 

  

 

[sjenkins]

So I said:

The question is would you rather OL is "dynamic" where it changes to last set or "static" where it starts default at 100 but when is set to something less it stays there until re-set. 

What I mean by that is that dynamic is OL changes based on the last on condition.

Insteon or Static, means you set an OL so every time you turn the light on it returns to that level, except fast-on which goes to 100%.  This is how the Insteon dimmers work.

 

give it a try, I just put it up in beta / non-production as v3.1.22

make sure you reset the AC and/or logout/in for eisy-ui as there are a number of profile updates in this one.

 

 

Edited 10 hours ago by sjenkins