PB Power On/Off strategy

Troubleshooting
1

I have two finished (I think) PB projects and few more are on the way.
All my projects are coupled with HE home automation hub.
With the help of HE hub I can send to PB logical Off command and/or
switch power all together.

My question is - should I keep power on 24/7 and use only logical
On/Off control or should I power Off all PBs say at 11:30pm?

Current implementation is:

  • When I need to turn PB On, a HE checks first if physical power switch is On
    If switch is Off the HE turns switch On, waits for PB’s “connected” status and
    finally sends all control commands to PB.
    If switch is already On the HE simply send all commands.
  • If I need to turn PB Off the HE simply sends logical Off command,
    physical power switch is still On.
  • At 11:30 the HE turns Off power to all PBs (and many other things).

I am asking these questions only because PB updates an EEPROM
at a certain points and if power is cut off during EEPROM Writes the
EEPROM could become corrupted and PB could become a nice brick
(unless this condition is somehow protected).

2

At 5V PB will use 0.6 watts, up up to 0.875 watts in AP mode. If your kilowatt hours cost you $0.20, then your PB will cost you $1.05 - $1.54 per year to keep running 24/7. If you turn PB off for 8 hours a day, you could save 35 - 51 cents a year.

As long as you aren’t actively writing to it, you can power PB off at any time. In theory, the flash filesystem should not be corrupted if power is lost during a write, but data loss would likely still occur on the file being written.

If at all possible, avoid doing things that cause writes using the API in any kind of automated / programatic way. The filesystem wear levels, but any kind of automated writes is likely to wear out the flash quickly.

1 Like
3

I believe, the default attribute value for saving variables is “false”.
In my automation I am not sending anything with this attribute set to “true”.
I can easily update all variables to required current values via WebSocket commands.

However if I am changing an active Pattern ID new one automatically memorized.
Is it any way to prevent this?
Basically I don’t need to memorize anything.
All controls are done via WebSocket regardless of current/previous PB state.

Power consumption is not a problem but potential EEPROM corruption
could be a problem.

4

Unless you send save:true as well, it won’t write to flash. It is set in the in-memory config, so if something else causes a config save it will get saved as well.

Some other config items default to saving unless save:false is sent, such as brightness. If in doubt, send save:false always and only the things that absolutely must cause a write will do so.

The playlist api doesn’t persist when switching to a new item, and has no related state. It could be a good alternative.

I haven’t updated the docs yet, plan to get that when I move things over to electromage.com…

Here’s a quick rundown.

There are 3 types of sequencers: Off (0), Shuffle (1), and Playlist (1). Changing it will save the config by default, send save: false to avoid that. Switch them with:

{"sequencerMode":0}

Sequencers can be paused/unpaused. This is not persistent.

{"runSequencer":true}

{"runSequencer":false}

Off and Shuffle are mostly the same. Off defaults to a paused state.

Every sequencer can be advanced to the next pattern, this is the same action as if pressing the button:

{"nextProgram":true}

In Playlist mode, the playlist can be switched to any item by it’s index:

{playlist: {position: 1}}

You can also set the playlist items. This will not persist unless save: true is set on the top-level message object. The position attribute can also be set on the playlist object, otherwise it will select the closest match to the old position. Right now only the playlist named _defaultplaylist_ is supported.

{
  "playlist": {
    "id": "_defaultplaylist_",
    "items": [
      {
        "id": "nG4DdjbTmZcReHpG7",
        "ms": 30000
      },
      {
        "id": "c4QEWwLheHnAuHPHX",
        "ms": 30000
      },
      ...
    ]
  }
}

You can have a playlist that isn’t running, and control things manually by setting the position or advancing to the next item (repeating over the list as needed).

1 Like
5

I am using a HE Driver written by @zranger1
Frankly I did not check what this driver is doing.
Good news is - I can create all custom commands just by using “Set Variable” PB API
bypassing what is built-in a driver is doing. My goal is - to minimize/eliminate all
unnecessary EEPROM writes.

6

It looks like brightness controls will write. I made a PR for @zranger1 that changes it.

7

Thank you, wizard.

My good guess, all controls from API by default should not / must not initiate
any writes to the EEPROM. Occasionally writes could be useful but this should
be initiated explicitly.

UPDATE
I searched @zranger1 driver for the “save” attribute and it is present only
for “Set Control” command. Plus it is possible to set “save” attribute to
false or true. So, driver is not trying to “save” anything explicitly.

However if I am sending “starting sequencer” command and than recycling
PB power next time sequencer is up and running.
If I am sending “stop sequencer” command next time the PB will play a
pattern what was active during “stop sequencer” command.
So, at least start/stop sequencer commands are automatically memorized.
And I don’t think this is something to do with a driver.
Am I right?

As I already mentioned, I don’t want anything to be auto memorized when
HE sends different commands.
How to prevent auto memorizing (if this is true) when PB is controlled via WebSocket?

UPDATE-2 @wizard

According to the WebSoket API description:

Controlling Brightness

The brightness can also be changed by sending a new value from 0.0 to 1.0. This is the same as the brightness slider, but will not be saved between restarts.

{
    "brightness": 0.5
}

brightness controlled via WebSocket should not be saved but in fact it is saved.
Driver simply sends a command described above.
So, the PB behavior is different from the description.

8

Apologies for taking so long to address this. I encountered a major medical issue and… actually, I had a small stroke while sitting at my computer desk. Weird. Felt a “pop” in my head and my vision started to disappear from the bottom up. Like it was going away scan line by scan line. At first I thought it was my monitor, then for a moment it was almost interesting to watch. Then it finally dawned on me “Ok - this is just not right!”

Anyway, I wound up in the hospital for a while, and then some days recovering. Far as I can tell, everything is ok again, but I’m going to be slower than usual for a little while.

I have just updated the Hubitat driver to give the option (on by default) of eliminating all EEPROM writes. However, doing so causes unexpected and possibly undesirable behavior on power cycling – in this case, a rebooted Pixelblaze will come back up with the settings last saved from the web UI, rather than from the hub.

Most of the rest of my smart devices, except for a few older, cheaper bulbs, remember their last settings after a power outage, and this is, I think what most people prefer. But it can certainly be done with fewer writes to flash.

So I have also given the option of saving settings after the controls have been stable for some period of time. This defaults to 8 seconds, but can be adjusted in Preferences to suit your needs.

As usual, the updated driver is available from my repo, or via the Hubitat package manager.

To give some reassurance about device lifetime, my oldest Pixelblaze has been in daily use since 2019 with the previous HE driver behavior and shows no signs of failure. Minimizing the number of writes is certainly an excellent idea though – thanks @wizard for the initial PR.

2 Likes
9

I am so sorry to hear this sad story but hoping for the happy end.
Strong Health is a priority #1!
I wish you fast and full recovery.

I will test the updated HE driver shortly.
In my specific case all my PBs are controlled from HE.
HE sends a full set of config parameters to PB.
This way I don’t want a PB to memorize anything at all.
But this is my very specific case most likely is not common for other PB users.

As far as EEPROM wear out goes, I guess, the number of rewrite cycles is 100,000
for the singe sector. It can/should survive about 30 writes per day during 10 years.
Not too bad. But this could be significantly increased if PB is using “rolling sectors”
for the storing the config data (could be already a case).
Anyway, removing unnecessary EEPROM writes is a very good idea.
I will let you know how the updated HE driver works.

And once again - I wish you fastest and full recovery.

10

There is no eeprom. It is flash. It does wear level.

11

Get well, @zranger1. Glad you are recovering.

12

Thanks for all the good wishes!

I’ve just posted a small update to fix a bug I noticed first thing this morning when I tried to turn the lights on that could cause on/off switching to “stick” in one state or the other.

If anybody downloaded last night, you’ll want to get the latest from the repo or the Hubitat package manager.

13

Ops,
Ironically I updated both my hubs just a min ago.
No problem.
I will update them again.

14

If you’re using the package manager, I think it only updates its index once a day. You may need to download manually. The most current version is 2.0.4.

15

I am manually updating driver to the latest V2.0.4 on my both hubs (C5 and C7).
On C7 first attempt failed with yellow bar on top with a message:
java.sql.SQLException: Version does not match, attempting to update version 1, current version is 2
So, I delete everything and did the update again.
Second attempt was 100% successful. I am not sure what was wrong on a first try.

C5 updated instantly without any problems.

Now it is time to test everything.
I will let you know how things is going.

16

Here are my test results:

  • Switch On/Off commands are working but Switch Status is not reported back at all.
    Since it was On before driver was updated the reported Switch Status is always On.
  • Set Level command is working but again, the reported status is whatever it was
    before driver update.
  • Since Level is not updated when Switch is turned On after being turned Off the
    Level is set to whatever value is reported.

The Effect Number is reported back correctly.

The updated settings seems to be not memorized even after the default 8 sec elapsed.
BTW, what is max setting for this timeout?
Is it 32767 which is about 9 hours?
Can I disable “settings memorization” all together?

17

Hi @vitaliy,
That’s a little strange. Level and switch state reporting works fine on all my devices. First, I’d try reinitializing the driver - press the Initialize button, then wait a second and press “Get Variables” and “Get Patterns” too.

I worry about that SQL error you encountered earlier. Drivers can’t interact with this subsystem directly. That’s a system error, and it may mean the hub’s internal database, which they use to store all state information, is having a problem. Power cycling the hub might fix it. If not, then this: Soft Reset - Hubitat Documentation is the usual way to correct database corruption. Pain in the tail, I know.

Edit: Oh, yes you can complete disable saving. Just turn the “Allow settings to persist through power loss. (May cause increased flash RAM wear)” switch on the device’s settings page off. It actually is off by default when you install the driver. You can also set the save delay to however many seconds will fit into a signed 32-bit long. Around 2 gigaseconds, I think…

18

Hi @zranger1

OK, Pushing the “Initialize” button did the trick.
Now everything works as expected, VERY BIG Thank You!
Actually, HE sends the “Initialize” command but only when PB is powered on
by physical switch (of course, controlled by HE).
Each my PB is equipped with dedicated smart switch and all PB’s power is
turned Off over night. At a morning time power to each PB turns On on a specific
triggers and during this initial power on HE sends “Initialize” command to the driver.
During the day PB’s On/Off is controlled only by On/Off commands only.
Power stays On until night time.

Ops, somehow I missed this magic button.
That is why nothing was memorized after 8 sec elapsed.
For the Timer I was thinking about 16bit PB limitation but actually this
timer runs on HE, not PB.

This was a very first time when I saw this error/warning on my C7.
Tomorrow morning I will do this “Hub Soft Reset” to clean up a potential DB
related problem. Right now it is not a good time for the interrupt - a lot of
automation is active.