7.31 works well. Did run the 7.30 since beginning as the update somehow works. Version is very stable and no issues for 6 weeks.
Remark: The integration of the Fibaro Roller shutter 3 is not fully solved. Integration works but 2 extra „shadow“ devices are generated. In addition, intermediate positions could not be triggered (e.g. open 20%)
I have a Veraplus Test System were the upgrade itself to1.7.4903 (7.31) worked without issues. But my RFXtrx433XL with Version 1041 and Tinman’s 1.87 Version cannot connect any more, even after going to Serialport config and change Baudrate and select the RFXtrx433xl.
My Veraplus production system still runs on 1.7.4783 (7.30) with RFXtrx433XL with Version 1041 and Tinman’s 1.87 Version without issues.
I believe I have to investigate more on my new test system as sometimes its not really clear for me were the RFXtrx files and icons (pictures) have to be on the >7.27 versions. In some 7.30 versions the folders were wright protected.
Just for information. I have upgraded to 7.31 and my RFXtrx still works fine. I didn’t need to update the serial port configuration. Running version 1.80
Thx for sharing. I see this only now, and it’s a very welcome news for the new year!
I join the list of thanks for the member of the community and the developers for this release.
Same here, but I had to change the Baud-rate and select correct unit. After that all works fine.
Coming out of my self inflicted ban. I haven’t read through all my PMs and quoted messages and questions in threads. As I intend to be less active on this forum if at all moving forward, I will continue to answer PMs and questions from members when time permits but am seriously considering developing an MQTT bridge to openzwave to replace the vera entirely on openluup.
Digging through all the issues and coming out of the holidays when I had a lot of people in the house, the vera started to hang on “tardy” and overwhelmed zwave command queue again and I am now convinced that there is no way the vera can be a reliable solution even as just a zwave device radio.
I don’t even run any scene or plugin and as I have expressed before, ironically the zigbee side appears rock solid because it appears to be a standard stack partial implementation as oppose to zwave on the vera being a very (proudly) creative implementation which lacked testing and has fundamental flaws.
We can get it to be 80% there by lowering the chattiness but the fundamental problem is in its command queuing and frame handling. This here is an example of what I still observe on 7.31 and outrages me:
01 01/02/20 7:30:16.052 ZWaveJobHandler::ReceivedFrame NONCE_GET flood node 17 <0x7e380520>
01 01/02/20 7:30:33.005 ZWaveSerial::Send m_iFrameID 14107 type 0x0 command 0x13 expected 3 got ack 1 response 44437568 request 0 failed to get at time 28885005 start time 28864991 wait 20000 ack 1 m_iSendsWithoutReceive 0 <0x7ef80520>
01 01/02/20 7:30:33.006 AlarmManager::Run callback for alarm 0x902ed8 entry 0x2a55308 type 52 id 25322 param=(nil) entry->when: 1577979013 time: 1577979033 tnum: 1 slow 0 tardy 20 <0x7ef80520>
01 01/02/20 9:30:55.456 ZWaveJobHandler::ReceivedFrame NONCE_GET flood node 203 <0x7e380520>
01 01/02/20 9:31:15.415 ZWaveSerial::Send m_iFrameID 20800 type 0x0 command 0x13 expected 3 got ack 1 response 47031776 request 0 failed to get at time 36127414 start time 36107402 wait 20000 ack 1 m_iSendsWithoutReceive 0 <0x7ef80520>
01 01/02/20 9:31:15.416 AlarmManager::Run callback for alarm 0x902ed8 entry 0x22eac38 type 52 id 34429 param=0x2722de0 entry->when: 1577986255 time: 1577986275 tnum: 1 slow 0 tardy 20 <0x7ef80520>
01 01/02/20 9:31:15.422 AlarmManager::Run callback for alarm 0x902ed8 entry 0x2a29cf0 type 52 id 34408 param=(nil) entry->when: 1577986256 time: 1577986275 tnum: 1 slow 0 tardy 19 <0x7ef80520>
Why you would hold down any command for 20s waiting for a frame is beyond my comprehension ability.
I installed this beta on my test vera plus yesterday and got it to run on my vera plus emulator.
First, kudos for fixing the Xmas lighting mode problem. It seems to be running ok and I think this was the most important.
A few notes I wanted to report which are not in the release notes:
-There is a significant increased of use of symbolic link in the rootfs/overlayfs. On this firmware, the team appears to have decided to move an even greater amount of the firmware into the read only partition to free up more space for the r/w partition of the overlay. This will definitely help stability and endurance of the flash drive on these units. It made it very painful for me to create my custom firmware image for my emulator but I will figure a way if I decide to stick around. The Luup engine (LuaUPnP) for example is one of the big files which was moved to read only but I can see the entire web server folder (www) and the core device handler folder (etc/cmh-ludl). This is better than nothing but to me feels more like a continuous patch for a fundamental problem which is the storage partition layout which should be redone for these devices so we can avoid all these song and dance.
-Extroot still does not work. The changes made to the kernel and storage management are preventing my extroot scripts from pivoting.
-The GUI is a little botched up under some conditions and browsers. For example my view of locks thermostat and spread across three columns under firefox but work fine on safari on the dashboard. It maybe related to the camera issue people are reporting. I also see a change in SSL for lightppd which I don’t quite understand the reason and was not documented… Well I upgraded my version and fixed the camera thing which again I don’t recommend people to integrate on the vera but this did not fix the dashboard layout problem on firefox.
8 Likes
Vera, mios, ezlo … you lost a real one
6 Likes
Have you considered a move to Home Assistant if you have not already done so. I think that platform would give you greater scope to express yourself. As a community effort you also get an opportunity to get your concepts across to a wider audience rather than feeling oppressed by a hierarchical structure.
1 Like
Truth here
C
I’m also running HA on a test Vera, the platform has a lot going for it. You would be more than welcome over there.
2 Likes
I’m there a while already. It’s not without it’s difficulties I might add but the load is shared more evenly. Running on a venv so a bit lonely 
but enjoying the challenge though. I’m not a big fan of spats either as it drains productivity. Hopefully matters will get back on track here.
2 Likes
I am there already as well. I have been running home assistant for quite some time. Many cloud and API integrations are going through it and is a child companion to openLuup just like the vera. I am streaming cameras, running facial recognition, controlling wifi devices like xiaomi, bmw, roomba, eightsleep etc with it but run all the logic into openluup. It would not be too hard to add my zwave and zigbee sticks to it and bridge them over to openluup. I once also contributed code to the project on GitHub. I was not a fan of the previous zwave device handling and even less of yaml but things seem to have improved quite a bit since then. Thanks for the suggestion.
I also have HA running on my unRaid server but I haven’t really delved into it as yet. When I was remonstrating about the lack of development people laughed, but that is besides the point, @rafale77 Lets us know where you decide to go before you do.
Might as well Ezlo, buy | license openluup and work on offloading the Os/Processing or use the Atom Os on the devices and move the processing off the controller. Make the controller passive/dumb and allow the UI7 to be run/emulated via docker/ jail. the Sercomm na502 /V+ at this point, I think simply just lacks processing capability to keep up with demands of today, mind you the controller has ALL the protocols Zigbee, Bluetooh, Bluetooth LE, just use the controller to send commands and offload the processing locally / not in the cloud
Did anyone tried to upgrade from 1.7.4001 to this beta?
Yes, did work. Please backup the system before
@rafale77 - does this work with your savespace script, or should I revert it before upgrading?
@anyone - did anyone performer upgrade with Vera connected over WiFi?
7.31 seems to be almost identical to 7.30. I still have luup reloads every 12 to 24 hours. Nothing major to report.
I have the same problem, as @rafale77 already knows. When this happens, weird things can occur (as lights turning ON or OFF magically and not when requested). My goto-sleep and away routines have improved a lot since the latest fws, but occasionally this could lead me to a luup reload and a not complete state (missing updates and such).
@edward anything you guys can think about in order to mitigate this problem in 7.32? Thanks.
PS: @rafale77, please stay with us. this community is what made me choose to start with Vera and stay with them. I know you feel dismissed by the other thread, but I truly believe we can stimulate them to have a better product - even they haven’t already realized that 
1 Like
Because of the way it works, the upgrade should work with savespace still on. To be sure, you could always revert it first. Not that this new firmware basically has savespace embedded.
Upgrading over wifi should work though I would not recommend it.