Help with turning off dimmer when light hits 1%

Other Devices & Integrations Lighting & Load Control
#41

IMHO, the way VERA pushes the firmware upgrades, requiring a factory reset, is an AWFUL process. What’s worse is that the pages they link you to on how to do it don’t actually give you all of the steps that are required. I’ve done it remote on my controller once, and it was pretty nerve-wracking. I took a slightly different approach, though. I did a full backup of the controller and ensured I had the copy of everything downloaded. Then I stripped out devices by hand until most of it was gone and there was enough room for the upgrade. The upgrade was pushed through, and then I restored a backup to put everything (including the Z-Wave network) back.

It is an abomination of a process and really needs to be addressed by VERA.

#42

IMHO, the way VERA pushes the firmware upgrades, requiring a factory reset, is an AWFUL process. What’s worse is that the pages they link you to on how to do it don’t actually give you all of the steps that are required. I’ve done it remote on my controller once, and it was pretty nerve-wracking. I took a slightly different approach, though. I did a full backup of the controller and ensured I had the copy of everything downloaded. Then I stripped out devices by hand until most of it was gone and there was enough room for the upgrade. The upgrade was pushed through, and then I restored a backup to put everything (including the Z-Wave network) back.

It is an abomination of a process and really needs to be addressed by VERA.[/quote]

Yes this last time the support guy told me about the deletion of apps and devices but really… is that any less nerve racking for me? No. MORE time consuming… Yes. I think the way they are addressing it is… upgrade your old controller. Which I get. I mean phones, computers, anything that has constant evolution will eventually be outgrown by it’s software counterparts. However, they could have taken the time to automate the issue all the while giving a warning that this or that will cease to be supported on a given date so we have time to plan for it. But it is what it is. I’m good not updating. I just need it to work along like the workhorse it’s always been. And thanks for the help. It would have taken me days to figure out that it was just two quotation marks. That’s why I love the forum. Smart people like you with experience. Hopefully someday I’ll be able to help someone too. Hell just by reading this it will help someone. Thanks again.

#43

The problem is that for example Plus has less storage space than Edge, (I’m not talking about RAM, but about the room where system files are stored) and as such “upgrading” may be in fact a “downgrade” in terms of stability and reliability.

#44

The problem is that for example Plus has less storage space than Edge, (I’m not talking about RAM, but about the room where system files are stored) and as such “upgrading” may be in fact a “downgrade” in terms of stability and reliability.[/quote]

Plus has less storage space? Other threads on here contradict that. How much less space? Do people with a new Plus or Edge have to reset to factory default before updating? That’s all I care about. I’m over doing that it with my beloved Vera 3

#45

The question is what memory we are talking about.
If you ssh to Vera and run “df -h” command, or run this command via AltUI OS.Command section, you’ll see following results (look for “rootfs”, “/dev/mtdblock7” and “overlayfs:/overlay” sections, as too much memory used here causes “no space left on device” error and problems with firmware upgrade or other issues):

For Vera PLUS rootfs, /dev/mtdblock7 and overlayfs:/overlay sections report size of 8,6MB, while for Vera Edge reported size is 9,4MB.
And this makes a difference of 800KB, which is about 10% of your total memory.

In practice, the same setup (restored from the same backup file) on Plus gives me memory filled in about 90%, while on Edge it is around 72%.
I don’t know why the difference is bigger than it should be when you compare just amounts of total memory of both controllers. Probably Edge needs less system files (i.e. no Zigbee or Bluetooth files) and this gives some additional space.

#46

[quote=“kwieto, post:45, topic:196577”]The question is what memory we are talking about.
If you ssh to Vera and run “df -h” command, or run this command via AltUI OS.Command section, you’ll see following results (look for “rootfs”, “/dev/mtdblock7” and “overlayfs:/overlay” sections, as too much memory used here causes “no space left on device” error and problems with firmware upgrade or other issues):

For Vera PLUS rootfs, /dev/mtdblock7 and overlayfs:/overlay sections report size of 8,6MB, while for Vera Edge reported size is 9,4MB.
And this makes a difference of 800KB, which is about 10% of your total memory.

In practice, the same setup (restored from the same backup file) on Plus gives me memory filled in about 90%, while on Edge it is around 72%.
I don’t know why the difference is bigger than it should be when you compare just amounts of total memory of both controllers. Probably Edge needs less system files (i.e. no Zigbee or Bluetooth files) and this gives some additional space.[/quote]
But at least you can do an update without resetting. That’s all I care about. I don’t know why I’d go with the Plus anyway since I don’t use zigbee or bluetooth. I can’t imagine the speed is all that much different for what I need them to do. The Vera 3’s speed is fine and it doesn’t have the capacity of either. The Secure seems like way to much money for not a lot of benefit. I don’t know, maybe the speed of the Plus and Secure is noticable?

#47

That’s not that obvious as it depends on your setup. Some people report having issues with “no space left on device” error on Plus, I don’t remember if Edge is also affected.
I had an issue where my controller upgraded, OK, but had issues after that upgrade. I couldn’t do factory reset due to lack of space on the controller - I couldn’t access it remotely, when accessed locally I couldn’t force factory reset from the menu (“insufficient rights”). When I did reset via reset button controller was exclueded from my dashboard, but after re-attaching it I found that all configuration still remain as before “reset”.
It took me half a day to finally wipe all data, but then, after restore it I’ve had other issues with it.
So, basically, no, you can’t be sure that you’ll be able to do an update without resetting.

#48

[quote=“kwieto, post:45, topic:196577”]The question is what memory we are talking about.
If you ssh to Vera and run “df -h” command, or run this command via AltUI OS.Command section, you’ll see following results (look for “rootfs”, “/dev/mtdblock7” and “overlayfs:/overlay” sections, as too much memory used here causes “no space left on device” error and problems with firmware upgrade or other issues):

For Vera PLUS rootfs, /dev/mtdblock7 and overlayfs:/overlay sections report size of 8,6MB, while for Vera Edge reported size is 9,4MB.
And this makes a difference of 800KB, which is about 10% of your total memory.

In practice, the same setup (restored from the same backup file) on Plus gives me memory filled in about 90%, while on Edge it is around 72%.
I don’t know why the difference is bigger than it should be when you compare just amounts of total memory of both controllers. Probably Edge needs less system files (i.e. no Zigbee or Bluetooth files) and this gives some additional space.[/quote]

Apologies if this comes off as pedantic… But memory and storage are two totally different things. I like to describe storage as the filing cabinet in the corner or the drawers in your desk - it’s where you “put things away” so that you can get to them later. Memory is akin to the size of the top of your desk. How much memory you have (RAM) is directly related to how many things you can take out of the drawers and lay out on the desktop at any given time. Swapping is like having to remove a piece of paper from the desktop and putting it in a drawer so that you have room to pull a different piece of paper out and lay it on the desk.

“df -h” is a command to check STORAGE.

#49

I’m not really familiar with naming.
Vera tells about Flash Memory (128MB for all current controllers) and just Memory (depending on the controller, from 128 to 512MB).

df -h command gives status of Flash Memory, I guess. But I’m not sure as in Plus case it doesn’t sum up to 128MB, but rather to about 200MB
Nevertheless, the problem is not the total amount of Flash Memory (Storage?), but sections reserved for system files (folders mentioned by me in some post above).
Here you have limited space of 8,6MB (Plus) or 9,4MB (Edge) which can be easily overfilled.
The “Memory” (RAM?) part unfortunately can also be issue and lack of this memory was most probably the reason for bricking my previous controller in a way that even Customer Care couldn’t revive it.

#50

Don’t feel bad—this is an issue usually reserved for Linux system admins. Linux commands are just like their Unix predecessors–information dense, but not friendly if you don’t know what you’re looking at. Embedded Linux systems use FLASH memory as the “disk drive”, the permanent storage that retains data even when the power is off. “Memory” is RAM (Random Access Memory) which may be written and read as often as desired at very high speed, but does not retain data when the power is off.

FLASH memory in embedded systems has limitations on how often it may be read and written before damage occurs to the memory cells. FLASH memory controller chips or system software is supposed to be responsible for “wear-leveling” to keep track of which blocks are used and to spread the workload across all the blocks. Good system software design tries to avoid reading and writing the FLASH as much as possible.

To help this problem, Linux has software, tempfs, that can use a portion of the RAM as a filesystem. Programs use this instead of the FLASH for temporary files. When Vera boots, all the operational code is copied from FLASH into RAM, and runs from there. Temporary files are created in the tempfs in RAM.

Vera Plus seems to allocate 50% of the RAM (128MB of 256MB total) to the tempfs. This is pretty typical for an embedded Linux system of this complexity. That leaves 128MB of RAM for all of the running code, plus buffers and scratchpad use,unless something goes wrong and an out-of-control process fills up the RAM. 128MB of RAM should be plenty under normal use, and the tempfs can be adjusted to be any size desired, if more RAM is needed.

My production VP shows this in response to the “free” command, which shows RAM use:

         total         used         free       shared      buffers

Mem: 255492 114868 140624 0 10308
-/+ buffers: 104560 150932
Swap: 0 0 0

114MB is in use, with 140MB free. This is the RAM, not the FLASH.

If you run the “du -h” command, it will show you everything in the FLASH filesystem with totals. Mine shows 119MB used. There is also a boot loader stored in the FLASH that does not show in the Linux filesystem since it isn’t part of it, but does take space on the FLASH chip. If the FLASH chip is 128MB, then it’s pretty full.

If we run the “df -h” command, we’ll see free space in the filesystem. The first thing to note is the 128MB of tempfs, which is RAM, not FLASH. But it is part of the filesystem and is displayed in this command.

The entries for devices, e.g /dev/mtdblock10 are parts of the FLASH memory, our “disk.” The devices are in turn mounted on the filesystem, for example /etc/cmh-firmware. This is how the physical device is connected to the logical device.

Here’s my overlay filesystem:

overlayfs:/overlay 8.6M 5.8M 2.9M 67% /

This is after weeding out unused plug-in files, and the 2+MB of regional Z-wave HEX files.

I have no idea why Vera has such small partitions, or why they can’t make the install script check before it gets into trouble, and clean up extraneous files. I took a quick look at the file system and it looks like there is a bunch of OpenWRT OS stuff that may not be needed for Vera. Perhaps they should take a look at that…

I see that akbooer has given you a script to check on the free space on /overlay. Kudos to him, and I hope it helps your system.

#51

What’s worse is why Vera insists on using these crazy small areas of disk to store files temporarily during an upgrade. They KNOW the limitations of their filesystem setup, yet they don’t afford you the opportunity to use a different area of storage purely for the upgrade process.

#52

I hope so.
I also did a major clearing of the remains from uninstalled plugins (I don’t understand why these files are kept and saved in backups even if plugin is removed) and probably go for removing regional z-wave files as well. The question is what in case of upgrade - as I understood, regional z-wave files will be recreated at that time and my concern is what will happen if the space will be already stuffed?

#53

Sorry been away for a while. So let me get this straight. If I upgrade to a Vera Plus in 2019, when I get the prompt to do an upgrade I could still get a message that tells me there is not enough disk space to do the upgrade? That’s wack. Wiping the controller and restoring a backup everytime there is a software update makes ZERO sense.

#54

Hard to tell.
Fist, it depends of your setup. In my case I don’t need to reset Vera to make upgrade, but I have to tweak it a little afterwards to avoid having issues with storage space. Depending on how big is your setup and how many plugins you use, you may encounter the problem or not.
Second, there is a lot of things happening at Vera currently. It was taken over by Ezlo, and the new owner declares improving a lot of things. Since lack of storage memory is known and affect many users, I suppose that it will be addressed.
For now we are waiting what will happen in the near future, and there was no new firmware upgrade yet since takeover.

#55

Thanks. I did contact support who came in and looked at my setup. He assured me I should have no issue upgrading with my current setup. I will take that with optimistic skepticism. LOL

#56

THANK YOU for the solution to this (seemingly basic) question about pre-setting a dimmer’s level prior to turning it ON. Been trying to do that myself with a GE/Jasco dimmer all day, using Reactor, to little avail, but this thread finally got me over the hump.

I’m wondering if @rigpapa might explain why “LoadLevelLast” never appears among the Device Actions we can perform in Reactor, when clearly it’s a known Advanced > Variable for that device?

(I’m guessing that Reactor is either hard-coded to display a subset of possible device Variables, without knowing which ones will work, or the device itself is lying about its implementation?)

I kinda hate having to spend two hours (as I just did) hunting up WHETHER you can do X with a given device, HOW one prepares to do it, and WHAT to set (or, in this case, script) to get it done. Honestly, without this Vera forum, my Vera would just be a doorstop by now!

Thus, I surmise that the “average user” wouldn’t have a chance in hell of figuring it out. Ironically, Reactor did offer up the aforementioned “OnEffect” and “OnEffectLevel” variables (which happen not to be among those my GE/Jasco dimmer lists nor, evidently, reacts to), but setting them as instructed above didn’t preset the dimming level.

But “LoadLevelLast” sure did. Thanks again!

  • Libra
#57

Does Reactor’s device database need an update perhaps?

C

#58

I’d like to believe (or am I being naive?) that Reactor doesn’t need to maintain a parallel knowledgebase of all prospective Z-Wave devices and their vagaries, versus simply polling the particular devices connected to your Vera and having them report what they are capable of.

If the former applies, then I’m still left wondering why I (the end user) can venture into a devices Advanced > Variables section, hover my mouse over an item, see its ‘serviceId’ and current value**, but meanwhile Reactor is somehow blocked from (or not programmed to) finding that same info.

**Is it just me, or do these Advanced > Variables seem loath to update themselves in real time?? I’m often misled into thinking my Lua script isn’t updating a variable to a new value, because the old value remains in the box even if I leave that page and come back. But upon clicking EDIT next to the box, voilà, there’s the new value hiding!!

#59

I can’t answer that, I’m afraid. But Reactor does have a some kind of internal list. I’m being really careful in my language here, as I’m almost certainly mis-describing it.

Take a look at the ‘Tools’ tab (assuming that you haven’t) and see if you think it might help

C

1 Like
#60

Actions and variables are different things, so I’m not clear what you’re after here.

I’ve gone to great lengths to avoid hard-coding anything with respect to devices. The variables you see listed in menus where a variable is to be selected are those defined on the actual device at that moment as provided by Vera’s JS API in its (cached) userdata. The actions shown in lists/menus of actions are those defined by the services enumerated for the actual device in the device’s own device file/declaration, with additional information drawn from a device capabilities database to identify the most common/useful actions in a service or particular to the specific implementation of the device.

There is no facility in Vera to determine if an action known to be part of a service the device claims to support is actually implemented by the device, or if implemented, the depth of its completeness or specifics and side-effects. As you’ve discovered, actions like those dealing with effects and effects levels may not apply to certain dimming devices. That means you sometimes have to pad around in the dark to figure out what works, and how. This is the Vera way.