2019 is here and 6month timeline mentioned to deliver is fast approaching, can we expect some big announcements 1st quater 2019?
No.
I wonder what the Chap from eZLO meant then:
And is the new focus/teams going to create any outputs (6months timeframe was mentioned last year)?
[ul]I wonder as well… I don’t want to be to sarcastic or critical but this is what I hear:
[list]
[li]They a working very hard on improving customer experience (they said they did last 8 years).
[/li][li]They are really listening to the customer (they did for 8 years).
[/li][li]on 2:00 mins he really sais: what is your problem we ar trying to solve (they don’t even know what they are solving?)
[/li][li]a LOT of buzz-words and promises…
[/li][li]Focus on OEM customers… I think the focus is not on end-customers anymore… hence the lack of communication
[/li][/list]
Well, at least the box is sexy (he sais) :-)[/ul]
Do you think that any OEM that prospects the market will choose MiOS/Ezlo if their existing deployed solution doesn’t look anything less than solid? You are wrong sir, Vera needs to be good and solid, and will be.
Communication is coming as promised and mentioned by Melih.
Do you think that any OEM that prospects the market will choose MiOS/Ezlo if their existing deployed solution doesn’t look anything less than solid? You are wrong sir, Vera needs to be good and solid, and will be.
Communication is coming as promised and mentioned by Melih.[/quote]
I do really hope so sir :-[
MCV basically crapped all over developers in the UI5 → UI7 transition, broke things that are still broken (thermostats), and generally took a platform that was headed in an amazing direction (much better vision than smart things). It’s been so crappy and unstable with failed hardware, unstable software releases, broken plugins (probably a large net result of hacking off developers and pulling the rug out from under them). Many people have moved to smart things, open hab, or up to control 4.
I basically only use my vera as a zwave lighting controller as it has proven unreliable for anything else. I pulled my garage doors, my leak sensors, my sprinklers, my alarm panel, everything off. I automate everything else via control 4 and I even have a mechanism to have control 4 reboot vera when it hangs every two weeks (honey, lights don’t work again…). I have thousands of errors spewing into my vera logs that come and go in waves, this week it’s temp filesystem log errors, next week it’s user json errors, the week after it’s a lua file that won’t load for some mysterious weekend. Dozens of tickets with MCV support where they either spend 2-3 days remoting in to my unit and fix it or tell me to take a hike because they aren’t going to fix something basic.
I’ve mostly given up hope. At this point I would be happy to have a stable IP <> zwave gateway I can use with a quality automation solution to maintain my investment in zwave lighting products.
If you guys are going to try and sell this to a commercial customer as an OEM product, I recommend scrapping it and developing something new. I would save the ZWave device code as that is the only piece that is worth a damn. I would also include some zwave troubleshooting mechanisms as there is currently no way to troubleshoot zwave anything other than adding/dropping it from the network (or you can install alt-ui and use the very nice carpet graph they have). Also, next product, don’t try and make it a networking device as well as an automation device… focus on core functionality, everyone already has wireless and a router no need to poorly implement that functionality and steal dev resources from the features people actually want.
[quote=“mindedc”]MCV basically crapped all over developers in the UI5 → UI7 transition, broke things that are still broken (thermostats), and generally took a platform that was headed in an amazing direction (much better vision than smart things). It’s been so crappy and unstable with failed hardware, unstable software releases, broken plugins (probably a large net result of hacking off developers and pulling the rug out from under them). Many people have moved to smart things, open hab, or up to control 4.
I basically only use my vera as a zwave lighting controller as it has proven unreliable for anything else. I pulled my garage doors, my leak sensors, my sprinklers, my alarm panel, everything off. I automate everything else via control 4 and I even have a mechanism to have control 4 reboot vera when it hangs every two weeks (honey, lights don’t work again…). I have thousands of errors spewing into my vera logs that come and go in waves, this week it’s temp filesystem log errors, next week it’s user json errors, the week after it’s a lua file that won’t load for some mysterious weekend. Dozens of tickets with MCV support where they either spend 2-3 days remoting in to my unit and fix it or tell me to take a hike because they aren’t going to fix something basic.
I’ve mostly given up hope. At this point I would be happy to have a stable IP <> zwave gateway I can use with a quality automation solution to maintain my investment in zwave lighting products.
If you guys are going to try and sell this to a commercial customer as an OEM product, I recommend scrapping it and developing something new. I would save the ZWave device code as that is the only piece that is worth a damn. I would also include some zwave troubleshooting mechanisms as there is currently no way to troubleshoot zwave anything other than adding/dropping it from the network (or you can install alt-ui and use the very nice carpet graph they have). Also, next product, don’t try and make it a networking device as well as an automation device… focus on core functionality, everyone already has wireless and a router no need to poorly implement that functionality and steal dev resources from the features people actually want.[/quote]
If you have not yet tried Rigpapa app reactor I would give it a try as it has added stability to my system after transferring scenes and device actions to his reactors which share parent code making multiple reactors light on resources and luup restart resilience.