I have the same setup with data being logged to a USB, however the plugin itself takes up 2.4mb which is quite large considering the partition is only about 8.6mb or so if I remember correctly. That is about 28% of the partition just for this one plugin. My guess is that anyone who has this plugin installed is having a similar problem.[/quote]
If storage space continues to be a problem, I am considering moving the rootfs of the vera to an external USB SSD.
Not for the faint of heart but could be the solution.[/quote]
So I ended doing the extroot, not that I particularly needed it but just for kicks using an external SSD and a USB to SATA III converter. I plugged it in and let the vera setup its logs on it. It will create a first partition called sda1 and then another partition sda2 for the rest of the drive. I copied over the content of the entire vera storage over to the remaining partition and made the vera boot from it.
The storage is actually a little slower because vera appears to have only exposed USB2 to its port instead of using USB3 which is a very strange decision.
Bus 001 Device 002: ID 152d:1561 JMicron Technology Corp. / JMicron USA Technology Corp.
Bus 001 Device 003: ID 0e8d:7662 MediaTek Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
As you can see Bus 002 has nothing connected to it.
It seems that the last firmware has issues with communication to devices.
I have periodicall messages that one or two devices are “offline” then “online” again with no apparent reason.
One device was offline for couple of days, then it started to work again before I found time to get to it and do anything to fix it.
From the other hand, it seems that upgrading Z-wave chip firmware (which was done in previous update) improved range of the network. My main controller has external antenna attached to it, but I have also a backup one, without such modification. I had to use backup one for some reason and found that it reaches also devices which in the past were unaccessible without an external antenna. My system changed during that time slightly, but the gap between closest devices (over 120m) didnt change.
Any idea how this survives during an upgrade?[/quote]
Yes… the answer is: it depends on the upgrade. If the upgrade does not upgrade the underlying openWRT OS, it will not affect it. I have gone from 7.0.26 to 7.0.27 and back and everything remained the same. It is possible though that a firmware upgrade of the OS which I suspect would break the extroot, specifically by changing the fstab file. In this case one would just have to repeat the procedure. I actually wrote a script to automate the upgrade in this case.
[quote=“kwieto, post:43, topic:199491”]It seems that the last firmware has issues with communication to devices.
I have periodicall messages that one or two devices are “offline” then “online” again with no apparent reason.
One device was offline for couple of days, then it started to work again before I found time to get to it and do anything to fix it.
From the other hand, it seems that upgrading Z-wave chip firmware (which was done in previous update) improved range of the network. My main controller has external antenna attached to it, but I have also a backup one, without such modification. I had to use backup one for some reason and found that it reaches also devices which in the past were unaccessible without an external antenna. My system changed during that time slightly, but the gap between closest devices (over 120m) didnt change.[/quote]
It completely broke my Zigbee network so I reverted. Your comment on range is a bit surprising since I did not see this version change the zwave db.
I don’t know when exactly was the change so I assume that it was more or less when the z-wave chip was upgraded to the 6-th version.
What I can tell is that half year ago I couldn’t reach my distant devices without external antenna and currently it is possible.
But It also can be due to weather conditions, although when I tested it it was stable (I restored the system on the main controller, which has external antenna attached, so I don’t monitor it anymore).
I started a new thread, but probably should have just posted in this thread. I am confused by the 7.0.27 firmware version, since I do not see that anywhere.
Anyway, everything was working perfectly until I did this update.
Now, my lights turn on at sunset, but never turn off. I have to manually reboot my Vera Plus every morning, then I can turn the lights off through the web interface.
I can see the event is being triggered like it should, but the communication seems lost with my z-wave LED bulbs until I reboot. I can still communicate with my door lock, so it is just my 3 z-wave light bulbs.
I have 4 of these Vera Plus units in 4 different homes. This is the only one I have upgraded. Soon I will not be at this house to reboot the controller every morning, so my home automation is no longer automated.
Any ideas?
Is there an automatic reboot scheduler I can run in the middle of the night that would simulate me rebooting the controller?
Hmm, Just updated to the latest firmware and I forgot the blue banner is now gone, is there a way to toggle it back on? It is helpful to know when the engine is reloading, as if I try to do stuff (like edit a scene) while that is happening sometimes it toasts the Concord 4 plug in, so like to wait until the blue banner is complete before moving to a new task. Can’t do that if I can’t see it
Yes. Go to Users & Account Info—>Notification Settings-----> Notifications Header (Additional diagnostic and operational messages displayed) and click the checkbox.
For those in the know …
Does anyone know where I can download a previous firmware version 1.7.3535 for VeraSecure?
I have been fighting 6 to 10 system reboots per day for 3 months now (most often at night between 3 a.m. and 8 a.m.), and support has not been able to fix it.
I did not have the problem until I upgraded to 1.7.3832 in May, and 1.7.4002 in August.
If there a way for me to install this via command line if my unit keeps getting stuck at LUUP is taking to long to load - suport has been looking at this for two weeks and i am wondering if this is a better hail mary than factory resetting?
I would recommend to go look at the vera storage layout thread and apply the storage remap script I wrote. It sounds like you may have flash overflow problem.
thanks I assume you mean the ‘VeraPlus Flash drive usage’ thread? I saw that when I noticed the issue, my root is only 57% full, I think… but maybe I am reading df wrong?
You are correct so based on what you are showing it shouldn’t be a storage issue. There is a way to run the upgrade through command line but it makes no difference compared to running it from the UI besides seeing the progression and outputs of the CLI. Try running the upgrade from the UI and upon reload, try to SSH into the unit. run “ps aux” and if you do not see the LuaUPnP towards the bottom of the list, issue the “Start_cmh.sh” command to start the luup engine.
@rafale77 thanks for the clarification, I can’t run anything via UI, I will try what you suggest in a couple of days, I am giving support one more chance (they say the enabled some extra debugging to find out what was going on and I am a big supporter of the principle of finding root cause, not working around it).
@RafaelPUP since March 25th (multiple reboots, delete of files, restore of backups - this seems to get unit back with UI for all of 15 minutes, then issue again)
–edit-- to be clear I think it has been this way since dec, (it is backup controller and test device) - that’s when it stopped doing backups… march 25th is when I noticed (trying to test new ios build) and logged support ticket
