UI7 ▾ Web UI ▾ 7.0.29 GA - April 24, 2019

Hmm, after the upgrade I have some weird things happening to my system.
Like: a switch, which is occasionally turning on by itself; an other switch, which is repeatedly reporting an “can’t detect device” error but when switched from UI reports back as working; a siren, which is repeatedly reporting as “tampered”, while not touched and not signaling any tampering (it should start the alarm when tampered with).
Don’t know if all issues are related to the upgrade, but they appeared at the same time, and all after the upgrade.

Maybe try to reboot? The only way I had this happen was when I had two instances of the luup engine running simultaneously.

Two instances of luup? On the normal setup?
Anyway, I did reboot and will see what happen

Yes, it is very rare but can occur when the luup reload script tries to kill one instance which is stuck before starting a new one.

if you run

ps aux

you may see two processes called “LUAUPnP”.

I have been fiddling with new updated packages in the mios opkg repo and after an update to the zwaveserial package am finding my vera having almost zero lag to zwave commands. A shocking improvement!

@rafale77 how did you update the zwaveserial package?

SSH into the unit and check what repositories are listed in /etc/opkg.conf
There should be a new mios repo with this firmware version:

src/gz G450 Index of /firmware/mt7621_G450/openwrt/ramips/packages/

If you don’t see it, add it.
Then run

opkg update
opkg list-upgradable

And see what you have available. Then run

opkg upgrade zwaveserial

You might get it by default with the firmware upgrade but since my unit was extrooted, I upgraded manually and am only now catching up to the rest of the upgrades.

2 Likes

I had something strange happen here too:
My 433mhz dawn/dusk sensor (through RFX plugin) all of a sudden is in the “No Room” room, set up as a dimmer, and with the same name + " 1".

It’s still working correctly, and the reactor/scene it was assigned to fires correctly…

The more I get into it, the less I know if I should laugh or cry.
For example, I have Netatmo weatherstation attached (via akbooer plugin). And when I checked recently external sensor (which is mainly temp and humidity) I see battery status 8% for temp and 70% for humidity. You know, it is the same device, just appearing as two sensor. I’ve check indoor (battery operated) module, and the same thing, 24% of battery for one device, 80% for the other.

Someone may say that it might be plugin fault or because Netatmo is not Z-wave but connected over the cloud, but why I have couple of wired (sic!) z-wave switches which present battery status as well?
And why some of them, which are double relays, present different battery status for each channel?

You know, false battery indicator is nothing important, but what is the warranty that the other things are working properly?

This is what happens when the device gets reconfigured. It is likely that the vera somehow corrupted some data for that device and decided to reconfigure it (creating a new identical one and enumerating the name and deleting the previous one).

@kwieto, what you are describing is either a plugin issue or… the vera misinterpreting some zwave command classes. I am more suspicious of the former. The battery level for any given device shows up because… at some point the “batterylevel” variable was created and assigned a value. I know of only two ways to do it: through lua code/plugin or the vera itself automatically creating it because it received that given command class (for zwave) or end point (for zigbee).
If you use ALTUI, you can actually get rid of them by deleting that very variable.

After some time out of my house I’m back with my problems with Fibaro Keyfob after upgrade. Finally I have removed the keyfob from the z-wave network and readded to my Vera Edge system as a Generic Z-Wave device.

Then I select scenes for devices buttons but it does not works in the right way. When I select diferent scene for single, double a triple click on certain button, it seems they are assigned to single click on other buttons. By example,
What I configure:
Tap Square: Turn on light 1
Double Tap Square: Turn off light 1
Tap Circle: Turn off switch 2
Double Tap Circle: Turn on swith 2

but the way it is actually working:
Tap Square: Turn on light 1
Tap Circle: Turn off light 1
Tap Minus: Turn off switch 2
Tap Plus: Turn on swith 2

Any help to assign double or triple click to the right scene?

exactly the same with me

Today I dramatically overhauled how I use iPhone Locator + Reactor and the result is minimal battery use and pretty responsive Home/Away Changes (IMHO).

Yes. 1 Veraplus and 2 Veraedge devices… all worked perfectly. Before you upgrade check the amount of space you have available and fix all known problems before your upgrade.

Hey, i’m having the same issue with my fibaro keyfob since the upgrade! I did try removing all the double and triple click scenes and recreating them with no joy and haven’t gone as far as removing it from the network yet (and probably won’t bother as you’ve already tried and adding this keyfob in the first place was problematic to say the least!)
I would be curious if you do manage to find a fix for this as the keyfob is pretty useless as it is!

Thx rafele77, i did The upgrade manually as you wrote.
I wonder why those packages do not upgrade automatically…

Ahh… This is one of the mysteries of the vera which gives it all its charms…:crazy_face:

One possibility is that it is already included in the firmware and that the dev forgot to update the opkg list. Another possibility as I had observed with lighttpd before is that they had it inserted at some point in their build but never released the build, waiting for the next beta.

I have been fiddling with new updated packages in the mios opkg repo and after an update to the zwaveserial package am finding my vera having almost zero lag to zwave commands. A shocking improvement!

@rafale77 - Thanks. I can’t wait to get home to check this out myself. For me, the new firmware has dramatically improved the stability of my system but I feel like Z-Wave performance could still be improved.

Just out of interest, have you been able to quantify the improvement in some real terms or does it just “feel” faster?

rafale77Beta

1d

SSH into the unit and check what repositories are listed in /etc/opkg.conf
There should be a new mios repo with this firmware version:

src/gz G450 http://dl.mios.com/firmware/mt7621_G450/openwrt/ramips/packages

If you don’t see it, add it.
Then run

opkg update
opkg list-upgradable

And see what you have available. Then run

opkg upgrade zwaveserial

You might get it by default with the firmware upgrade but since my unit was extrooted, I upgraded manually and am only now catching up to the rest of the upgrades

^^^
Is this possible to do this in Start Up LUA using OS.execute commands?

For me it is a matter of lag for my automation scenes…
When I come home I have about 20+ zwave and zigbee commands which runs on top of disarming sensors, I have lights, vents etc. When this scene runs and I trip a motion sensor, I normally see a lag of 2-3s before I get a TTS annoucement when I don’t have these heavy scenes running and I get 5-20s lag with these scenes running. I eliminated the 2-3s making it 0s by making the vera send updates to openLuup instead of waiting for openLuup to poll. (did this a long time ago) but was left with the large variable lag. Since the update… I have had none. Pretty stunning. I am speculating that there is a command queue built into the serial interface package which was not working before or was not used adequately and that it is now fixed.

@zedrally. Yes it can be done. Pretty easily. I am just used to want to see the returned output of these commands through SSH. In particular checking if the repo is already in the opkg config file. If you already upgraded to 7.0.29 I suspect that you should already have that repo so the commands should be:

OS.execute(“opkg update”)
OS.execute(“opkg upgrade zwaveserial”)

1 Like

Just sharing a data point.

I have five Vera Plus controllers at five different properties.

Two of them updated seamlessly. Three of them updated but then failed to properly restart. I had to visit those three properties and physically power-cycle the controllers to get them to boot and reconnect.

Controller #1 (succeeded): only one Schlage lock paired
Controller #2 (succeeded): only one Schlage lock paired
Controller #3 (failed): only one Schlage lock paired
Controller #4 (failed): one Schlage lock and one Z-Wave thermostat paired
Controller #5 (failed): one Schlage lock and one Honeywell thermostat plugin installed

As you can see, I don’t have a lot of memory usage or anything on my devices (one or two paired devices at most).

The only commonality I can think of between controllers #3, 4, and 5 (the three that failed) are that all three are on a connection that uses a combo modem/router provided by Suddenlink (my cable ISP), whereas controller #1 and #2 (the two that succeeded) are on Mikrotik routers, so maybe there’s something involving how the router responds to a DHCP lease request after reboot or something. That’s all I can think of on my end, anyway.

All is well now (after manual power cycling), but just wanted to report my experience.