I give up

What rigpapa said.

I’ve spent 45 years designing embedded control systems for entertainment and architectural lighting. My first system in 1975 had a DEC PDP-8/A minicomputer with 16K words (12-bit word) of magnetic core memory. The entire operating program was 8K words, with the remaining 8K for cue storage and executed around 250K instructions per second. It ran a major Broadway musical for 13 years with no problems.

I did a small controller in 2005 (32-bit ARM, 180 Mhz, 128MB RAM, 16MB FLASH, our own embedded Linux) that takes in steaming Ethernet at 100 Mb/s and output two 250KB/s RS-485 streams while doing substantial processing on the data. The system never got above 0.1 utilization, and my lab unit has been on the bench without rebooting since 2006. It can be done.

And a big contributor is also constant external and internal pressure for new features, which I'm sure Vera's engineering team gets in volume, never leaving the time to go back and really review and clean house, unless something is on fire in that area. There's no reward for going back and making it work better; just make it work and move on, turn and burn. That is what I think Melih should change, because it's affecting more than just performance.

Bingo! And this is endemic in the software industry—it’s not just a Vera/Mios problem. I wish Melih and his new combined team all the best, but we need to be realistic. Any merger is a huge challenge, and it will take time to build the new organization

[quote=“rigpapa, post:99, topic:199599”][quote=“RV, post:98, topic:199599”]I’d have more to say but a goodbye thread is probably not the best place but I’m going to say this again anyway.

hardware is cheap.
put some memory and storage in the Vera. I can buy a Raspberry Pi or a Pine64 off the shelf for $40 and have a better computer than what’s in the Vera.

Perhaps we should move this “what can melih do for us” to a new thread like “Suggestions for melih” or “Suggestions for the new owners” or “Suggestions to melih for Vera going forward”[/quote]

Put me in the camp of people that disagree that dialing up Vera’s hardware would do much for performance.

My production Vera Plus (well over 100 Z-wave devices and another half as many virtual/plugin) sits at a one minute load average of 0.2 right now, and is rarely much higher. That means that averaged over one minute, there is 1/5 of a process waiting to run or running. It is effectively idle. It’s also got 124K mem free, which may not seem like much in the absolute by today’s standards, but it’s around 48% of system RAM–that’s quite a lot. There’s plenty there waiting to be used.

Most of the slowdowns I have observed on Vera are the result of bugs or other problems: some people show evidence of memory leaks (and many do not); some people have troublesome Z-Wave devices that bog down the mesh; Vera single-threads too many operations; etc. Who knows what’s going on internally. But based on what I see and my own experience, most of the problems could be addressed by finding and fixing bugs, and optimizing code and behavior, not by throwing more hardware at the problem. Doing the latter, in fact, will solve nothing–it will just defer the effect of those memory leaks until the greater amount of memory is filled, or have a faster processor sitting waiting for I/O at the same clip as the older slower one. Storage would be useful to boost, but that’s about it, in my view.

I’ve so far spent nearly 40 years feeding myself as a software engineer. Over that time I’ve watched the industry become progressively more lazy, and lose the skills that were once vital to doing useful work when the only RAM you had was 64K, or 16K, or 4K. Software engineers and “coders” today are overly dependent on Moore’s Law for addressing their performance problems.

And a big contributor is also constant external and internal pressure for new features, which I’m sure Vera’s engineering team gets in volume, never leaving the time to go back and really review and clean house, unless something is on fire in that area. There’s no reward for going back and making it work better; just make it work and move on, turn and burn. That is what I think Melih should change, because it’s affecting more than just performance.[/quote]

I agree. the problem is not CPU power problem…software problem…we are on it…

Personally could not agree more. When I was using X10 kit I had an ADI Ocelot. It was a PLC device with naff all memory or cpu power. It was, however, incredibly reliable and it was amazing what you could do with the 2,000 or so lines of code you could squeeze into it. What I did was have everything that I wanted to be certain to work running on that - lights going on when doors opened, that sort of thing. Stuff that was less important I ran on something else (for quite a while a perl based system called Misterhouse, later Homeseer). In general I found everything reliable, but when it failed it was always due to something I’d done to the misterhouse/homeseer side - either from adding in more stuff or doing an update. The Ocelot just kept on ticking away.

Throwing more memory and CPU into a Vera may help that device to stay up longer if it is having issues with memory leaks etc, in a similar way that scheduling a regular reboot can help with availability, but does not address the root cause.

As much as I’ve had issues with my Vera, I do not want or intend to stop using it. I reckon it’s a brilliant device, albeit with some issues. The problems I’ve seen people describe can generally all be addressed by tracking down the root cause - such as a faulty app or device. I also managed to get my Vera to be pretty reliable, but it was never stable enough for me (keep in mind I come from a background of decades of working in the computer industry designing & implementing highly available systems for the enterprise). My plan is to now use my Vera in the same way as I used my Ocelot. I am cutting it down to the basics - removing all the third party apps that may have introduced memory leaks or other issues - and just let it control my Zwave devices. At some point I will do a clean install on it to make sure I’ve wiped away anything bad. It will then have the critical job of sitting there and making sure the important things always work, and I’ll only touch it if/when I get new Zwave kit. The “fluffy” non-critical stuff I’m putting onto a 'pi that is running Home Assistant.

RV, google HA automation examples and look at as many of these as you can. I’m more than happy to help, but I put in a 13 hour day today and have another 12 tomorrow. Needless to say, I’m not able to focus on much at the moment. Tuesday I can dig up some stuff though…

thanks man, no hurry, I’m just finding the Vera/HA integration documentation a little lacking.

I learned over a year ago - don’t fiddle with Vera unless you have to. I added a wall switch and light bulb about 3 months ago, added/changed some PLEG logic, and it took about a month of fiddling to get those changes, and the original setup, to work, consistently. For the last 2 months, it is humming away, stuff happening when it should. Recent problem was not Vera but router related. New router fixed that. I get LUUP starts but I ignore them. One time, Vera actually rebooted. So not fiddling with things was my long term solution to my past frustrations.

That’s not really a fair comparison in the slightest. Veras are fully featured computers, not dedicated PLCs or DSPs.

Encrypted cloud connections, web server, video camera streaming, logging, email, a rules engine, script parser, and zwave network management (zwave by all accounts is the most CPU intensive HA system). Oh, and a plug-in framework and the plug ins themselves.

With quad core Pi3s running $35 retail, there is no justification in being CPU or RAM poor these days.

[quote=“kigmatzomat, post:107, topic:199599”]That’s not really a fair comparison in the slightest. Veras are fully featured computers, not dedicated PLCs or DSPs.

Encrypted cloud connections, web server, video camera streaming, logging, email, a rules engine, script parser, and zwave network management (zwave by all accounts is the most CPU intensive HA system). Oh, and a plug-in framework and the plug ins themselves.

With quad core Pi3s running $35 retail, there is no justification in being CPU or RAM poor these days.[/quote]

I know - it was an extreme comparison, but I was just implying that I was hoping to get similar levels of reliability by reducing what I was using Vera for. In general I find my Vera doesn’t use much CPU or ram. It is remarkably efficient, actually. The problem seems to be when an app or some other thing ‘goes crazy’ and starts eating resources whether that’s memory/cache/disk or cpu. The ‘solution’ tends to be to use a script to clear the cache/memory or perhaps schedule a regular reboot. Or simply ignore/live with the problem. Putting in a machine with more memory or a better CPU will most likely only make the issues less frequent. I prefer to stop it from happening. :wink:

If you cast your mind back to Windows way back when, that too needed to be rebooted regularly. Slowly Microsoft worked out some of the major bugs that ate resources, and setup ways to protect the core system from being impacted by rogue apps so now Windows can run reliably for extended periods without an issue. Hopefully the ‘fresh blood’ will be able to work on making the platform itself more reliable. Not saying that next releases of hardware shouldn’t take advantage of the faster CPUs and greater amounts of memory etc that are available, but there appear to be some basic issues that could be worked on to make the existing systems way more stable.

I will hold out for a little bit longer. I was about to order a Hubitat, but am intrigued if there will actually be any improvement. I have a small system, pretty basic, maybe a dozen devices. Only thing I had to customize was after the change from UI5 to UI7 had to add custom Luup code since they removed the ability to turn on a device then after a period of time to turn it back off or to its previous status. I used that with my motion sensors and a custom scene that can be triggered manually.
Reviewing the forums, it seems that the Luup is causing some issues and thinking that is why I will often find lights on when I awake when they should have been turned off at midnight, or scenes not even being triggered at all…maybe.
The hardware, although lacking when compared to a Pi, was more than adequate under older versions, and seems to be problematic as updates continue. The best days were when I had the original Vera and pretty much forgot it existed, it just worked.

I don’t think the hardware is even on his radar, really. The router your home ISP gives you, or the LinkSys/Netgear/Ubiquiti you prefer to it, probably has more computing power than current Veras, or soon could. Likewise every cable and satellite set-top box.

Do you see where this is going?

RV, the direct documentation can be, and often is, very lacking. It mostly just shows you how to incorporate the item. There are many examples posted, some with very good descriptions of how they work, that will come up in a google search. I’ll be off tomorrow…

As much as I’ve had issues with my Vera, I do not want or intend to stop using it. I reckon it’s a brilliant device, albeit with some issues. The problems I’ve seen people describe can generally all be addressed by tracking down the root cause - such as a faulty app or device.[/quote]

spot on! There was a mis-management issue with development where it was allowed to release software with bugs in it…major and critical bug…this is simply a NO NO for us the owners! We do NOT tolerate this kind of development environment and putting the processes to eliminate this kind of outcome.

I?ve been digging around in the uploaded examples in Examples - Home Assistant.
I think I may have found what I wanted.

As much as I’ve had issues with my Vera, I do not want or intend to stop using it. I reckon it’s a brilliant device, albeit with some issues. The problems I’ve seen people describe can generally all be addressed by tracking down the root cause - such as a faulty app or device.[/quote]

spot on! There was a mis-management issue with development where it was allowed to release software with bugs in it…major and critical bug…this is simply a NO NO for us the owners! We do NOT tolerate this kind of development environment and putting the processes to eliminate this kind of outcome.[/quote]

[quote=“RV, post:113, topic:199599”]I?ve been digging around in the uploaded examples in Examples - Home Assistant.
I think I may have found what I wanted.[/quote]

Great. There are many examples there as to what you can do. Keeping in mind that I am definitely not recommending that people leave Vera for HA (there is a learning curve with yaml), but if someone is having issues then consider using HA to move some of the workload off the Vera (to improve stability) as well as provide some of the additional smarts that Vera lacks at the moment. Hopefully in the future the updates proposed will make this unnecessary. As for the equivalent of scenes in HA, they are generally called ‘automations’ and are kept in the file ‘automations.yaml’. For example, the following turns on my front porch light if there is movement detected from a couple of hours before sunset to a couple of hours after sunrise:

- id: entrance_motion_light
  alias: Turn on entrance light at night if motion
  trigger:
    - platform: state
      entity_id: binary_sensor.entrance_sensor_331
      to: 'on'
      from: 'off'
  condition:
    condition: or
    conditions:
      - condition: sun
        after: sunset
        after_offset: "-02:00:00"
      - condition: sun
        before: sunrise
        before_offset: "+02:00:00"
  action:
    service: homeassistant.turn_on
    entity_id: light.entrance_light_189

Then the light is turned off 10 minutes after no motion has been detected:

- id: entrance_motion_light_off
  alias: Turn off entrance light at night if no motion
  trigger:
    - platform: state
      entity_id: binary_sensor.entrance_sensor_331
      to: 'off'
      for:
        minutes: 10
  action:
    service: homeassistant.turn_off
    entity_id: light.entrance_light_189

My Zwave motion sensor is device #331, and my light is #189, in Vera. FWIW You can also use ‘input_boolean’ to create things like a vacation mode so lights go on/off when you are away, as well as the workday_sensor which I use to have things like heated towel rails go on/off at different times depending on whether it is a workday or not (eg on weekends or holidays the heated towel rails go on later in the morning) - something I only dreamed of doing on Vera.

Oh, and FYI I think to do your sound thing you could just add something like this into your configuration.yaml:

shell_command: play_sound: curl "http://192.168.0.2/sound.php?file=fdo&volume=100"
and you can then add in multiple actions by changing indenting the service with a dash

Personally I’d do something like

    - service: tts.google_say
      entity_id: media_player.living_room_speaker
      data: 
        message: 'The door is open'

…but up to you. :wink:

Actually, HA has scenes as well. They are defined in the configuration file and, like Vera, are little more than a list of things to be executed when triggered. I haven’t had a use for them yet as the only scenes I’m using are a combination of different lights on and off on my pool deck and the switch that controls them is on the Vera. I haven’t found a way to move it to HA and it works flawlessly where it is. I haven’t had a Luup reload in over a week…

thanks guys
I tried something similar yesterday and it didn’t do anything.
Today I’ve been stripping the file down to the minimum and I’m about to try it

automations.yaml

[code]#automation: Kitchen lights on when door opened then off again
alias: Kitchen lights on when door opened
trigger:
platform: state
entity_id: binary_sensor.kitchen_door_1_65
from: ‘off’
to: ‘on’
action:
service: light.turn_on
entity_id: light.kit_eat_light_dim_14
brightness: 255

alias: Turn off Eat in Kitchen lights
trigger:
platform: state
entity_id: binary_sensor.kitchen_door_1_65
to: ‘off’
for: ‘00:00:10’
platform: state
entity_id: light.kit_eat_light_dim_14
to: ‘on’
for: ‘00:00:10’
condition:
condition: state
entity_id: light.kit_eat_light_dim_14
state: ‘on’
action:
service: light.turn_off
entity_id: light.kit_eat_light_dim_14

[/code]

and I don’t want to leave Vera either. I just need scenes to work immediately and not in minutes.

We will get it to work!

ninkasi. I got your code to work without the shell command
thanks

RV,

Start simple and add to it as you learn how and why it works. I’ve been tweaking a virtual rain sensor for about two weeks. I think I have it figured out now with the help of the template editor. WOW! Not sure how I could have done what I’ve done under Vera, but it most certainly would have involved PLEG and a bit of coding…