MIOS Acquisition

It will be interesting to see what they will do. Will they continue to do support for old hardware, or move on. They are providing some backward compatibility, but only time will tell how long that will last. We all know the existing system has some BIG problems.

Sent from my iPad using Tapatalk

[quote=“svaleb, post:518, topic:199656”]@ Melih
Could you please enlighten us about this device !
http://forum.micasaverde.com/index.php/topic,52628.0.html

The Fibaro radiator thermostat FGT-001
It has been impossible to integrate for more than a year.
If you have time to read the tread please tell us what is wrong.
Support cannot do it and there is comments from Sorin.
We would like to know.
Please ![/quote]

Svaleb, we’ve FGT-001 samples and we look forward to integrating these devices, but because they require some core changes in the firmware in order to get them to configure correctly, we will be targeting them in the next release after 7.29. I’m so sorry for this taking this long but I’m sure that with the new forces on-board, things will move a lot faster.

Thanks Sorin.
Are you able to tell us what makes this, and a few other devices,so different.
Something must make them very special ?

FGT-001 uses a newer implementation for radiator thermostats when comparing it with the existing ones in the market and requires updates to the supported command classes.

And is this also the cart blanche to not support “all devices” on the market? How does this relate to that promise?

BTW I am SO exited that finally all my dreams come true in terms of Vera really going to support zwave!

Thanks Sorin.
I will quote that to the tread.
It differs a bit from your latest remark in the tread.

[quote=“svaleb, post:526, topic:199656”]Thanks Sorin.
I will quote that to the tread.
It differs a bit from your latest remark in the tread.[/quote]

Don’t shoot the messenger :slight_smile:
I’m only giving you guys, whatever info I have at that moment in time. Things can change during the analysis phase.

since we are at Fibaro’s new devices, what about the smart implant? Is that supported out-of-the-box? Thanks Sorin.

In my case the updated IOS app is working fine so far. I just wish the Fibaro Double switch 2 gets better code in vera’s next firmware upgrade to fix the (sending the zwave command after 0 or x tries) issue.

Also, although I prefer to have a more stable system in general, still I agree with Melih that, it would be better to lower the price of the controller.

If Melih’s company can also manufacture reasonably priced embedded switches, sensors, etc… that are fully compatible with vera out of the box would be a very good move in my opinion.

[quote=“joseph.ahd, post:529, topic:199656”]In my case the updated IOS app is working fine so far. I just wish the Fibaro Double switch 2 gets better code in vera’s next firmware upgrade to fix the (sending the zwave command after 0 or x tries) issue.

Also, although I prefer to have a more stable system in general, still I agree with Melih that, it would be better to lower the price of the controller.

If Melih’s company can also manufacture reasonably priced embedded switches, sensors, etc… that are fully compatible with vera out of the box would be a very good move in my opinion.[/quote]

which switches/sensors are a priority in your view?

[quote=“melih, post:530, topic:199656”][quote=“joseph.ahd, post:529, topic:199656”]In my case the updated IOS app is working fine so far. I just wish the Fibaro Double switch 2 gets better code in vera’s next firmware upgrade to fix the (sending the zwave command after 0 or x tries) issue.

Also, although I prefer to have a more stable system in general, still I agree with Melih that, it would be better to lower the price of the controller.

If Melih’s company can also manufacture reasonably priced embedded switches, sensors, etc… that are fully compatible with vera out of the box would be a very good move in my opinion.[/quote]

which switches/sensors are a priority in your view?[/quote]

Fibaro FGK-107, door/window sensor, that still seems not to be correctly configured at least in VERA Edge and there is an open thread since time ago for a similar one (FGK-101), http://forum.micasaverde.com/index.php/topic,48423.0.html , that says to be a known issue by support but seems not to have been corrected yet, at least in my case I get the exact same error described in the ref. thread.

Regards

[quote=“melih, post:530, topic:199656”][quote=“joseph.ahd, post:529, topic:199656”]In my case the updated IOS app is working fine so far. I just wish the Fibaro Double switch 2 gets better code in vera’s next firmware upgrade to fix the (sending the zwave command after 0 or x tries) issue.

Also, although I prefer to have a more stable system in general, still I agree with Melih that, it would be better to lower the price of the controller.

If Melih’s company can also manufacture reasonably priced embedded switches, sensors, etc… that are fully compatible with vera out of the box would be a very good move in my opinion.[/quote]

which switches/sensors are a priority in your view?[/quote]

An embedded switch such as the very robust/reliable fibaro double switch 2
Motion sensor such as the philio psp 05 (i find the fibaro 3 in 1 a bit gimmicky).
A door/window sensor

Edit:
I would like to add that it would be useful to have security sensors powered via either battery or external dc adapter with micro usb connector or a two pin screw terminal for example.

I am hoping that the Atom will at minimum work with all the devices Vera supports right now. Right now the compatible device list on the Ezlo site is really short. This will be critical to success of the system. Also will want local control of the devices when internet is down.

Sent from my iPad using Tapatalk

yes, indeed.

@Melih,

I’m speaking as a user and also as an IT pro since that is my day job.

You will fail if your focus is on creating an ultra cheap hub that has limited support for devices. I would happily pay $100 for a hub that supported 5 times more devices than $10 for a hub that supported 5 times fewer devices. Why? Because the TCO (total cost of ownership) of the system is the following:

the hub hardware
my time invested in learning how to use the hub
the devices
my time invested in learning how to use each device

Which part of all of this is the cheapest?

In homes you have weird things. For example I have a sliding glass door that doubles as a main entrance door. The only maglock in the world that is reliable enough to use on that setup is many hundreds of dollars. And there’s only 1 out the because nobody is stupid enough to build a house with a sliding glass door as the font entrance - except for the weirdo (long dead by now) that built mine.

You also have interior doors that exist in rentals to block strangers out of areas they aren’t supposed to be in that need maglocks that are also specialty

You have a need specialty detectors because your city is backwards when it comes to codes and makes you do stupid nonstandard stuff. Maybe you need integration with a tsunami warning system because your city requires you have a tsunami warning system.

Anytime you go off the beaten path with the devices the costs skyrocket.

The TCO of a fully tricked out home automation system is 99% sunk into things that are NOT the hub hardware. And the majority of it isn’t hardware it’s the hours and hours spent installing and adjusting the hardware and programming it.

I get it that you want a $5 device that can be used as a sales hook and hang at the checkout stand. You should know of course that once you start selling them within 6 months Ebay will be flooded with them from people who drop the $5 into the device, take it home, discover it requires some commitment to get running, and give up. You are probably fine with that since the device will just move to the next person and the goal is to get fishes snagged you are assuming that only 5% of the fishes you caught will stay around for the long term.

But once you get a fish, and the fish starts playing, and wants to connect this and that and the other thing - if the fish can’t add on some zwave or zigbee or wifi device he bought for $5 down at goodwill, or that his cousin gave him because he mentioned that he was “gettin into” home automation, or that came from some other automation system that foundered on the rocks - the fish is going to swim off.

I don’t care if you think some device out there is an antique thing that was abandoned by it’s maker 3 years ago and they must be all thrown away now. They aren’t. They are sitting at the bottom of some techie’s junk drawer. And if that techie one day is cleaning out his drawer and pulls out the devices - punches it’s model number into Google - and comes up with it listed on your compatibility list - you will be worshipped. You will have him for life.

I don’t know how old you are or how long you have been at this game. I’ve been at it for 35 or so years. I clearly remember how Microsoft got so big - for many many years you could plug in a windows 95 or 98 disk and install it and it would support the most grody old printer or wand or scanner or whatever other old peripheral out there that may have existed 15 years earlier. They didn’t even draw the line at supporting QIC drives plugged into the floppy disk controller and those were the definition of a hardware kludge - on their SERVER product no less.

Your goal should be “we support EVERY DOORLOCK, CAMERA, KEYPAD, SENSOR, CAMERA, BLAH BLAH BLAH THAT HAS EVER BEEN MADE INCLUDING EVERY COMPETITORS DEVICE INCLUDING THE PROPRIETARY ONES” Obviously there’s not enough time to actually do it but that should be your goal.

The service revenue will come. But do as Microsoft did and support EVERYTHING. Microsoft did this and collected EVERYONE and only once it did that did it start telling people with grotty old hardware that needed to be laid to rest to go pound sand. You don’t have EVERYONE so you can’t do that yet.

I was late learning that Mios had been acquired, and even later discovering this wonderful thread, from which I take only encouragement. Seeing some of our “big guns” - guys and gals way smarter than me (and I’m pretty savvy!) - participating in the conversation gives me hope for the Vera platform. I like that @melih is listening so intently, too!

To chime in, as a Vera user since Day One (I was the guy who wrote the original FAQ/Wiki over 10 years ago!), a once-chronic forum poster (these days I merely lurk), and now a VeraPlus user since my Vera 1 died…

  1. Everything that needed to be said about former company practices has, IMO, been said. The airing of grievances has been welcome and, honestly, refreshing.

  2. I’m still in shock that anyone in a position of authority and inside knowledge has taken the time to respond. Again, I take this as an extremely positive sign!

  3. Reading this thread forced me to take inventory of where I stand, from an allegiance standpoint, and how I’ve come to feel about Vera overall…

  4. … Answer: Going into 2019, my thoughts were, “If my VeraPlus ever dies, I’m ditching that platform and will find an alternative. ANY alternative.”

  5. Because all of the “bugaboos” encountered over the years – IFTTT development seeming dead in the water; stagnant forum; poor/conflicting/confusing documentation; infrequent firmware updates; risk of borking/slowing system just by adding plug-ins (so many I want to try but dare not!) – I’ve learned to just shut up and accept the minimum. Not a good stance for any consumer to adopt!

  6. Speaking of plug-ins, I’ve long thought that corporate ought to be PAYING devs to make awesome plug-ins and LICENSING/ADAPTING their talents to future UI updates, rather than keep their products in a separate/opt-in ecosystem (where skittish users like me may never try them for fear of “clogging Vera’s memory”!).

  7. Lastly, bravo to everyone who has spelled out the shortcomings of existing hardware and OS management, such as frequent restarts and concomitant problems arising therefrom. While no one of us can know all the issues, MOST of us understand SOME of the issues because we are affected by them daily. (I came here indirectly today because I set out a few hours ago to reset my ecobee app PIN, yet again, only to find their server down… again.)

  8. One word: API – it’s the flagship of all modern connected products, and there’s no reason in 2019 why Vera shouldn’t be NATIVELY talking both ways with automators like IFTTT and Stringify, services like ecobee (and 100’s of others), gateways like Amazon Alexa AND Google Assistant, triggers like Tasker, etc., etc.

As @melih said, and I’m paraphrasing, “No more Frankensystems!”

I’ll shut up now. Thanks for listening, everyone.

  • Libra
2 Likes

@TedM : Our goal is our hardware should work with everything commercially available natively.
@LibraSun : Thank you for taking the time to check back in. We are building a “Platform” not a widget!

2 Likes

Libra,

Let me throw one more nugget out to digest on this issue.

“there’s no reason in 2019 why Vera shouldn’t be NATIVELY talking both ways with automators like IFTTT and Stringify, services like ecobee (and 100’s of others), gateways like Amazon Alexa AND Google Assistant, triggers like Tasker”

That is a huge obstacle. For starters some of those other parties don’t WANT the Vera - unless Vera comes into their office with a bag-o-cash. The home automation market is young and small enough that companies like Amazon still have dreams of being the sole-source for EVERYTHING. Vera runs it’s “store” as a “defensive” measure - they sell stuff like detectors not to make a pile of money on them but because it’s easier for the newbie to come in who, say, wants a camera and they can just go to the Vera store and buy it and they are guaranteed it will work. For example, try buying the CORRECT model of Centralite keypad anywhere other than the Vera store. Amazon by contrast is doing Alexa as an OFFENSIVE measure - they want customers buying EVERYTHING from them - the hub the devices the programming etc. etc. That is because their goal is to put golden handcuffs on people like me and get us to pay them $9.95 a month for our home automation to work.
And every last home automation device maker on the market thinks EXACTLY THE SAME WAY. When I was looking to buy my thermostat I spent hours researching. Honeywell is the single largest thermostat maker in the world. They have exactly ONE device that will work with Vera - and only work very grudgingly - and a dozen thermostats that work with their proprietary service - a service that RIGHT NOW costs nothing - unless your commercial - but there’s no guarantee that service will be around and won’t suddenly start charging residential customers.
Except for the no-name Chinese device makers who just want to get in, sell something for $25, then get out and don’t bother calling them if it doesn’t work exactly right, every device maker on the planet has a bad bad case of “meism” Honewell thinks it’s OK to charge $10 a month, Schlage thinks it’s OK to charge $10 a month, the list goes on and on. If you did home devices “by the book” you would be paying hundreds of dollars to 2 dozen different vendors and have 2 dozen different apps on your cell phone.
These device makers HATE home hubs like Vera because it cuts into what they want to do - which is extract a monthly recurring revenue stream from the customer. They don’t WANT to support Zigbee, etc. and when they do it’s the most half-assed minimalist implementation they can get away with.
So for Vera to work with EVERYTHING - which you and I and melih all say we want - someone has to be doing things that the device maker really really doesn’t want. Someone has to be calling Honeywell every day asking “when are you going to put the capability for a screen lock on your thermostat into zwave” And they need to be publicly calling these companies out so that customer pressure forces them to do it. Vera should have a list of EVERY LAST DEVICE on the market that speaks Zwave and Zigbee and a pass/fail on it on whether the device works, and whether or not it works well and what is missing. I have read about deadbolt locks for example that have keypads and the lock only reports open/close status back via Zwave yet the manufacturer touts Zwave capability in their marketing. So the customer buys it expecting to get a usable keypad with Vera and - they are screwed. Oh sure they can tell if the lock is opened or not. Maybe they can even open and close the lock. Based on - what? Without keypad data from the lock’s keypad - they are SOL.

I have been using FreeBSD for many many years. In the early years the programmers were guerrillas. They would reverse engineer stuff like video cards right and left. Nvidia for example for many years refused to give out info that was not under NDA which is incompatible with the BSD license. But the programmers weren’t telling people “don’t buy those cards” instead they were loading up debuggers and reverse engineering stuff.

It is only in rare cases that a manufacturer responds to “gentle pressure” Such was the case with APC (purchased by Schneider Electric) For years their UPSes were controlled by the long-ago-reverse-engineered UPSLink protocol. APC never bothered supplying UPS software that ran on Debian linux or BSD just windows powerchute. Then one day they got the bright idea to change to Microlink a properitary protocol. The response from admins was to start pushing them to open this protocol - but as it turned out - they themselves had foolishly signed an NDA with some Asian chipset maker who developed Microlink and wouldn’t let them open it - so APC went out and created a new protocol - Modbus - for UPSes and opened that. Nowadays a brand new SMT1500 UPS can support all 3 protocols if desired. A huge waste of programmers time on APCs part but they stepped in dog poo and had the decency to admit it and clean it off.
But then again a SMT1500 costs $1200. A door lock costs - $100-$150. Or less. I doubt any of the door lock manufacturers would give a rat’s ass about Vera nicely asking them for interface specs.
So to get to our goal here requires Vera to get nasty. Vera needs to greatly expand the compatibility list to encompass both “compatibility” and “incompatibility” They can tell a maker like Honeywell “you want your stuff off our do-not-buy list, you fix the bugs in it” They need to reverse engineer to show companies that they won’t tolerate proprietary solutions in the market, and if a company tries putting one out they are going to tear it open. This is the kind of fighting FreeBSD had to do for many years. It doesn’t work right away. But gradually it changes the world.

1 Like

Very very insightful post @TedM TedM. Thank you for the time spent on it.

I agree with your assessment of the current market and what the big dogs are trying to do to block out the local home hubs like vera and hubitat. Samsung ST, Amazon, Google etc have taken the strategy to drive this market into the cloud to try to charge a monthly fee and get annuity out of this business model.

The issue from my engineering perspective is that the cloud adds near zero value but add technical liabilities besides the potential monthly cost and it is why I am still supporting hubs like vera for now and hubitat. Devices like nest, ecobee, ring, skybell all rely heavily on the cloud with various level of dependance for their most basic functionalities. Even if the cloud services are free to some extent today, I decided to take them all down for technical reason and have moved everything local.

For thermostat, there are plenty of perfectly good zwave and some zigbee ones working on the vera.
I have eliminated any device of any kind which do not have a local API. Even down to my TTS server for my announcements have moved to a local macOS service and I am no longer relying on MS Bing, Amazon Polly or google. Moved the doorbell to an RCA version which has a RSTP stream to my NVR…

So for Melih, I too am very concerned about your claim about trying to work with everything commercially available. It is not an easy task and one which could lead to a lot of headaches and failures. All the energy should be put on supporting the zwave and zigbee stacks. The IFTTT, Stringify, google homes etc… are all interesting but secondary “nice to haves”. They will be utterly useless if the vera’s device control stack or hardware is flawed or unreliable. The previous team, I perceive has tried to do too much with too little both in resources and in hardware capability and if it wasn’t enough even poorly implemented the hardware (read my threads about the storage usage on the veras and all the absurd bricking after upgrades it has caused). If the primary local device handling is rock solid then supporting everything else is more power to you and to the new team.