[quote=“rlkoshak, post:18, topic:8792, full:true”]
Often these big companies see a shiny new object (i.e. a new or emerging market), want to get in on the action and so buy a smaller company…[/quote]
@rlkoshak
holy $#!T! (also title of one of my new favorite songs lol )
Wow…thanks a lot for the well thought-out and detailed response with so many depressing examples lol
It’s times like this that I’m, once again, reminded of how naive I am when it comes to things like this.
Great…more depression lol
Indeed.
I don’t AT ALL mind the time spent IF the system is stable, reliable & consistent. Troubleshooting how I f*c#3d something up because I’m an idiot, or I didn’t read carefully enough (again, idiot), or because the device I have is broken or not supported or whatever is one thing, but when everything I have is on the ‘approved’ list, and I’m a genius in the HA field (not me, but seen it plenty ‘over there’), and it’s all configured with exact precision according to specs, and it STILL doesn’t work, then god dammit, it’s just a big PITA! lol
Since the System ‘over there’ has NEVER been stable, nor reliable, nor consistent in the past couple years that I’ve been there, and since - lately anyway - it’s been getting much, much worse (not just in reports from others, but in my own experience), especially over the past few weeks, I’m done…
Not done with SmartThings completely, but done with the mindset that it will be my only HA solution for the long-term (or even the idea that I’ll only have a single or dual HA setup long-term; I need to branch-out, regardless, in order to keep up with what’s out there, etc if nothing else, and it’s now so acutely obvious that having multiple viable HA ‘cores’ is absolutely necessary).
Now, not only am I considering OH as a ‘backup’ solution; but also as a complete replacement for my core HA environment.
Of course, I know there are still things left to be desired here too, but holy crap…it works right?..even ‘most of the time’ (which certainly can’t be said ‘over there’)?
Thanks a lot for the input here, guys.
I still don’t actually have enough time in the near-term to actually do this (sorry for so many days between my responses, etc), but it’s the highest priority on my free-time-list, and I will begin testing (at least in a minor/marginal way) sometime in the next month or so; one way or another.
I might suggest you think about a more modular architecture which will somewhat decouple the dependency of your HA devices and the “core.” This will be a bit more of a long term thing for you and it will likely involve a lot of work, but if you provide/create a standardized interface to your devices rather than integrating them directly with the “core” it will be much easier to swap out your core and one part of the system going down or running amok will not has as big of an impact on the rest of your system.
For instance, standardize on a few generic technologies (e.g. MQTT, HTTP, and TCP/IP) and only use those to get information into the core or send commands out of the core. Then where necessary use/build/write a bridge that goes between one of those protocols and the native protocol. Then, if your zwave network goes bizzerk it won’t kill your Mobus network, or whatever.
But I will note that I have found the OH core to be one of the most stable and reliable programs I’ve ever used either professionally or personally. I have no concerns with having everything integrated on the one core and have not made any effort to do the above in my setup. About the only additional thing I am looking at doing is to run it in a Docker container which should make managing it just slightly easier to manage and let me lock down the container in ways I don’t want to lock down my whole machine. I’m not sure it will add much real security but it sure will be fun to learn about. And I like the idea that should everything go belly up I can just pull my config and Dockerfiles out of my backed up git repo run docker build to rebuild the services. I can be back up and running in minutes.
Can’t read it now, but I will later this evening or tomorrow.
For now…it just keeps getting worse ‘over there’…
p.s. I know it’s probably not at all related to the Melt-Down that is STILL going on and STILL not identified, but still. I just thought it was funny. lol
Not sure where you were trying to link to; just goes to their main forum.
I had an abusive relationship with my Vera. I’d try and use it, and it’d abuse me. Very nice to be free from it! (…nearly. Still have it running my locks for now.)
Thesis 1: Indeed, Samsung likes to provide a little bit of integration with their devices. For example, I could control a Samsung TV (if I had one) with my out of the box Samsung tablet (if I had one). But, Samsung is perfectly aware that, unlike Apple, they cannot succeed in this IoT market without allowing other Android phones and Apple phones to also interact. Having worked with, used, and owned Samsung mobile devices it is very clear that Samsung knows it must embrace the full Android ecosystem and beyond (after all they didn’t pull the iOS ST app when they acquired ST). And it remains to be seen whether Apple will ever be more than a bit player in this market with their semi-closed HomeKit solution. MS has the same problem with their Windows 10 IoT stuff, though their built in support on Raspberry Pi does help.
A Samsung phone may have a little bit of extra out of the box integration but a Samsung phone won’t be required and a Samsung phone certainly won’t be the “brain” of the system. That would make no sense from either a business nor a technical perspective. And remember, mobile phones makes up a tiny fraction of all the businesses Samsung has its fingers in. It is likely that this IoT division is completely separate from their phone division so even that little bit of extra integration may not be there at all. In other words, they may try to leverage the IoT OS integration with their phones as a selling point but they are not going to make that a requirement.
So Thesis 1 is pretty much true for EVERY IoT-System that allows phones to control them, including openHAB. So your snark applies to everyone, not just some Samsung IoT OS and that is why I called it a non-sequitur.
Given that, snark aside, this is actually a really good topic for conversation (hence my wall of text).
Thesis 2: I work in computer security so follow this topic closely. And I’m not any sort of “fan boy” of any company/OS/technology. I say this because what I’m about to say may come off as defending Android from a “fan boy” perspective.
At this time the threat of Android viruses is hugely overblown unless you are in China and/or using shady third party app stores. For the vast majority of users in the world, the threat of Android viruses is pretty low to nonexistent. And the security of phones across all three major OS’s is improving rapidly. And neither iOS nor Windows phones are immune to viruses and other malware and across the board I expect more mobile device viruses on all platforms. And finally, mobile phones are basically computers with an antenna so they will NEVER be immune to viruses.
So let’s assume that in the future Android devices will be more prone to viruses than the other major platforms. Given the above, that fact is really mox nix because ALL phone platforms will have the potential to inject viruses into your home network and therefore IoT deployment. You cannot just assume that because you are using an iOS or Windows phone your are safe.
So once again, I agree but the problem exists for all phones and for all IoT platforms, including openHAB.
Absolutely, steering an IoT system with an infected device can have an impact on the IoT system. But this is a systemic problem, not just a Samsung or Android problem. It is something that even we openHAB users (and HomeKit users) must think about and be prepared to deal with in the not too distant future.
But what is the real risk near term? I could write pages and pages of analysis on this question so I’ll put in a tl;dr version here.
the risk of a phone getting a virus now and for the near future is exceptionally low
the risk of a phone getting a virus that can move laterally off of your phone and onto other computers on the network is vanishingly low (actually given the shared OS platform between iOS and OSX, iTunes interaction for iOS devices, and between Windows 10 and Windows Mobile, this sort of virus is actually more challenging to pull off on Android)
the goals of most malware is to either take over your machine to use in a botnet, steal your information for identity theft, or extort money. Only the first of those goals would be attractive enough for a malware author to write something that would infect a phone and move laterally to an IoT device. And right now security on IoT devices is so low it would be far far easier to just infect the device directly. So the motivation of writing a malware for a phone that would impact your IoT directly is also vanishingly low.
So, while IoT security is an important topic, and phone security and in particular phone’s a vectors for malware is an important topic, the actual risk to your average user’s IoT system from phone borne viruses is vanishing low at this time. I see nothing unique about Samsung’s announcement that makes IoT any more or less secure than it and any other IoT platform already is.
On the other hand, I have major questions and concerns about this Samsung IoT OS’s security posture. For so many of these sorts of IoT solutions thoughts of security is kind of an afterthought or minimal at best (e.g. hard coded passwords, backdoors, unsecured clouds, unsecured network connections, weak or no authentication and authorization, etc). But again, I have these same questions and concerns about all IoT platforms and devices.
Finally, I’ll also fall back to my old maxim, “If your home automation (HA) requires human interaction to work it is an HA failure.” Put another way, HA that requires using a phone to control it isn’t HA, it’s computer controlled, and computer controlled is almost never as convenient or human friendly or as expressive as using the traditional controlling mechanisms (light switches, remotes, etc.). So if your HA system requires a phone to run it, I’d argue that is your root problem, not the potential for mobile phone viruses.
I don’t agree with this sentiment at all. Automation is automation, regardless of trigger method. For example, one of my most called rules is to turn on my living room TV. (Using the term TV loosely here.) That’s actually a multi step process:
Turn on amplifiers
Turn on preamp
Lower screen
Turn on projector
Turn on computer
Now it would be far less convenient to have to walk over to the projector and hit the on button, walk over to the amps & preamp and hit its on button, walk over to the screen controller and hit lower, and then finally hit the power button on the computer. Even when I had it all going with X10 it was a three different remote affair. With OpenHAB, it’s one button on a scene controller. Or if the scene controller is stuck in the couch cushions, I fire up my phone and trigger it that way. It’s certainly a thousand times easier than the no automation way, regardless of whether I’m using the scene controller or my phone! And due to projector bulbs being really fricken expensive, I don’t want any automation system automatically assuming that when I’m in the room I want to watch TV… I often don’t! (That’s about the only way you could trigger it with no intervention required.)
I was reading the headlines yesterday and wondering when this (or a similar) conversation would head towards Revolv! That was a large part of why I moved to OpenHAB; being an independent system one could (theoretically, very theoretically) nuke the planet and it’ll still run just fine.
I did forward the Revolv news to my wife yesterday with “See? SEE??? SEEEEEEE!?!??!?!” under it. I throw up enough caution flags that it’s nice when some adverse situation actually occurs in the real world that we get to collectively not care about. (Sucks for them, but I want my points! )
Rules of thumb and maxums are almost never complete, nor true in all situations, nor always possible to live up to.
They usually represent an ideal to strive towards, a goal.
The key points I mean by human interaction being an HA failure are:
The ideal is the house should just do it, I shouldn’t have to tell it to do it
Where 1. is not possible, triggering the automation should be as easy or easier than the traditional non-automated control (e.g. turning on a light should be as simple and easy as flipping a switch). This would also cover cases where you might need a confirmation.
Where 1. and 2. are not possible reconsider whether integrated HA or any HA is the appropriate solution (e.g. just use a motion sensing light switch, a simple outlet timer, etc.). Sometimes the best solution is no automation at all.
I’ve summarized all of this into one glib little sentence primarily as a means to cause a lot of users to sit back and think about what their goals are and what they are doing. I see a lot of users building up these huge computer controlled home systems and stressing way out on the sitemap who have never even considered the idea that maybe all of these controls aren’t needed.
Agreed but it would be even more convenient if it could figure out when you want it turned on and just do it. That is what I mean. 1. should be the goal.
You’ve implemented 2. quite nicely.
Actually that isn’t the only way. There is all sorts of things you can take into account or implement. Some initial ideas:
require a confirmation (I do this for the garage opener) before doing the automation
time of day
number of people in the room
entered the room and turned down the lights but didn’t turn them off
machine learning system which learns to anticipate when you want to watch TV
any combination of the above
There are all sorts of ways one can conveniently implement a confirmation. I use a Tasker dialog on my phone as the only times I’m likely to want to open the garage automatically my phone will be mounted to my dash and visible. But there are relatively simple auditory or physical ways you can do it as well (e.g. play a beep and clap your hands to confirm would only require a tiny speaker, Arduino/Raspberry Pi/cheap board computer and a loud sound sensor).
It may not be worth the cost/time/effort to implement something like this but as you add sensors to your system there are more and more opportunities for the system to make smart decisions that allows it to do more automatically.
Convenient yes but it’s an unfeasible goal without mind reading capabilities. Sometimes I sit on the couch to read a book. Sometimes I sit on the couch and watch TV. Sometimes the wife is around, sometimes not. Sometimes the lights are on, sometimes not. Devil is in the details, and there are a lot of details that wind up being “sometimes”, and no “always” details.
(chuckle) All the automation did was change which button you’re hitting on your phone! “Do this” or “yes, you have permission to do this” isn’t meaningfully different in my book; both require intervention.
I see the larger point of what you’re getting at, I just don’t agree it’s reasonable to say that interaction automatically makes HA a failure and disqualifies it as automation. I think the more distinct uses a space has, the more interaction is required and less unattended automation is possible. Automation is still possible, however.
That is where we disagree. While I agree that the devil is in the details, finding that one detail or combination of details that is always present when you want to watch the TV is all it takes to have a working trigger. There may not be one but just throwing up your hands and saying it’s too hard does not equal impossible.
No, I went from
close Waze to get to the home screen
open openHAB
press the garage button
to
press the confirmation button
I don’t get a confirmation request when I manually trigger the garage from OH. I only get asked for a confirmation when the garage thinks I want it opened automatically (i.e. I’m driving and entered my home geofence). And as long as it requires some sort of navigation on the phone to get to the button this confirmation will always be fewer steps.
This firmly fits within my 2., have the interaction be as simple or easier than the non-automated way (i.e. press the button on the remote the garage door came with). And I initially didn’t even need the confirmation but had to add it because the driving activity detection on my new phone sucks and I haven’t spent time figured out a fix yet.
My maxum is admittedly and purposely a little hyperbolic in order to make a point. To many seem to focus on the human interaction with their HA system without even considering no human interaction as an option. And I came up with it primarily as a pithy way to make people think. It was never intended to be reasonable.
Ultimately most arguments come down to semantics. To me, Home Automation is when the system does things automatically, i.e. without interaction. Computer Control is when the system does one or more things based on some sort of human interaction. Using Computer Control does not mean the system is a failure, it just means that that particular activity potentially has room to grow. Both “automate” steps to things but the distinction is in the trigger. And I say that requiring human interaction is a failure to hyperbolically drive home the point that full automation should at least be considered as an option. I don’t literally mean that all Computer Control systems are failures.
If I were to write a book on the topic the above paragraph would probably be a whole chapter.
It depends a lot on the automation goals. For example, no matter how varied the use of a space is, climate control is relatively easy to automate. Sometimes lighting can be completely automated. sometimes it makes sense to not even automate or computer control things you might be technically able to. It all depends on the use cases.
So to put it plain, no hyperbole:
I do not think your audio/visual configuration is a failure. To the contrary, I think it is pretty awesome.
I would not call it home automation but I would call it computer control and the distinction is not a value judgement against computer control (so long as the control is as easy or easier than the no-computerized control).
I do not think it is completely impossible to make your system completely automated, but will readily concede that it is likely not worth the effort.
My intent by calling computer control a HA “failure” is not to malign computer control but to get people to get out of the “I could do x” mindset and into the “I should do x” mindset. Just because you can control something from your phone doesn’t mean that you should.
Fair enough, and I think that’s where this whole disagreement really originates. For me, automation has a much more nebulous definition of something that simply makes my life easier; I don’t draw a distinction between things that require zero interaction and things that require one interaction. (I do draw the line at two. ) That encompasses everything from having a light on a remote control that I still have to push a button to turn on to things that would qualify under your definition of HA.
Ah, that makes more sense now; thanks for the clarification. (Plus it’s about time we got back to talking smack about Samsung & Google. )
Anyone up for a renewed meeting of the SmartThings support group?
I’m working on an OH2 beta build running on an RPi3. I bought an Aeotech Z-stick to keep my existing Z-wave devices and so far it’s working well. I was thinking about getting a Zigbee dongle, but i read elsewhere that SmartThings own Zigbee devices are closed and can’t be paired elsewhere. I only have one other zigbee device so it’s probably not worth the effort.
I decided to build items and rules around a similar setup to SmartThings modes. I’m having a hard time with presence - I hate draining the battery on my phone with geofences but haven’t worked out my final solution yet. One interim idea I had was to use IFTTT to update an OH switch with my presence states from ST. Not a long term solution, but it certainly might help me make my transition to OH if I can take some time to implement a better presence solution.
Longer term, I want to design some Arduino Uno based hardware for porting my project over from SmartThings. Once realized, it’ll bring an RGBW LED strip control, a piezo alarm, and an array of sensors to any location it’s installed. It’s ideal for permanent installations, such as running kitchen lights and hiding the wiring in the cabinet. Wired nodes will use MQTT, and I’ll have a gateway device communicate to the rest over NRF24L01 sensors. If and when it’s in good shape, I’ll share the code and build instructions as I did over on SmartThings (although that iteration never left an alpha stage).
That and the ZigBee binding is not yet released. But if that is how SmartThings and ZigBee works I find it ironic that the supposedly not open standard has the most restrictions.
These are the approaches to presence detection I’ve seen. Usually more than one is used at the same time:
geofences using OwnTracks or IFTTT
on Android using Tasker to push presence to an OH Item when the device joins the home wifi network
detecting the device on the network using a number of different approaches including scripts running on the routers, ARP sniffing, Network and Network Health bindings, ping run using Exec binding, etc.
I personally use a combination of Bluetooth and Network Health binding and am very happy with its accuracy, even for my wife’s iPhone which goes to sleep and becomes invisible to Network Health.
)
) That encompasses everything from having a light on a remote control that I still have to push a button to turn on to things that would qualify under your definition of HA.