Jump to content

Smarthome Sale 10/20 - 10/24/2021


Teken

Recommended Posts

Posted

He should do a stock IPO offering on the market and get some money and a board of directors that have some marketing drive and knowledge.

Posted (edited)
1 hour ago, larryllix said:

board of directors that have some marketing drive and knowledge.

volunteers ?

Michel, Lilyoyo1 and Teken ?

Edited by asbril
Posted

@asbril,

Not that any of this means anything: I still have much doubt on how INSTEON can compete with devices that have public key security at a fraction of the cost. INSTEON payload (even at 24 bytes) is just way too little to support good security. And, if we were to redesign it, then we'd be spending all our lives in testing/regression testing.

With kind regards,
Michel

 

Posted
volunteers ?
Michel, Lilyoyo1 and Teken ?

I spent more than 25 years in senior management as what people often call a corporate raider / head hunter.

My primary job was to identify why the company wasn’t profitable to than turn it around if possible or to shut it down. Managed 2500 companies which encompassed more than two billion people. I’d love to identity the problems at Smartlabs and resolve them.

Sadly, this company doesn’t conform or follow any industry best practices as it relates to business. Nobody, and I mean nobody keeps pushing out the same junk and just changes a capacitor thinking that’s the fix?!?

They don’t follow any Lean 6 Sigma standards never mind ITIL.
  • Like 3
Posted
25 minutes ago, Michel Kohanim said:

@asbril,

Not that any of this means anything: I still have much doubt on how INSTEON can compete with devices that have public key security at a fraction of the cost. INSTEON payload (even at 24 bytes) is just way too little to support good security. And, if we were to redesign it, then we'd be spending all our lives in testing/regression testing.

With kind regards,
Michel

 

Michel

I was joking and I don't think that it would be worth your time, though it would certainly be beneficial for Smarthome/labs.

As you know I dropped Insteon 7 years ago and I follow these discussions, on the future of Insteon, with some bewilderment.

  • Like 2
Posted
Michel
I was joking and I don't think that it would be worth your time, though it would certainly be beneficial for Smarthome/labs.
As you know I dropped Insteon 7 years ago and I follow these discussions, on the future of Insteon, with some bewilderment.

You’ll come back to the dark side one day!
  • Haha 2
Posted
1 hour ago, Michel Kohanim said:

@asbril,

Not that any of this means anything: I still have much doubt on how INSTEON can compete with devices that have public key security at a fraction of the cost. INSTEON payload (even at 24 bytes) is just way too little to support good security. And, if we were to redesign it, then we'd be spending all our lives in testing/regression testing.

With kind regards,
Michel

 

Curious how important that is? I have never had my lighting system hacked or had anybody gain access to my network by hijacking my Insteon hardware. I have never heard of anybody else that this has happened to. No personal information exists in my PLM. I don't use Insteon for a security system and would not expect to. To my knowledge there are no Insteon based door locks and there are easier ways to break into a garage than hacking an Inston remote garage door kit. 

X10 is plenty secure for a lighting control protocol so what more do you really need from Insteon? And what protocol has public key security (at any price) that doesn't flat out suck as an alternative to Insteon?

  • Like 1
Posted

Regarding importance: it's a market limiter.  There are those who feel security, even on lighting systems, is important.  There are those who will be required to have security (by their landlord, their company, or other organization with authority over the implementation).  In addition, there are areas of automation that require security, moreso than lighting -- for an automation protocol to be viable it really does need to automate locks, and cameras, and other applications where security is simple required.

The common objection is "but I don't care if some hacker starts blinking my lights!"  I don't doubt that -- but not everyone feels that way.  It's the same with your Android device, and your Window computer at home -- many people I know don't have a lock screen enabled, and remain logged in all day long.  You should have the right to link your devices to the controller in a similar "no-security" fashion.  But if the protocol doesn't support security, it's going to be limited.  As an analogy, consider that PC -- fine for an individual, perhaps, to have no lock screen and no strong password, but if no better security was available in Windows then Microsoft would have lost out the entire business marketplace.

Security sucks in general, that's true.  It's always going to suck, just like fumbling for my freakin' car keys in the rain with both arms loaded with groceries sucks.  But just like I'm still going to lock my car in the parking lot, I'm going to live with security on my devices.  It would be nice to be able to selectively disable it, for ease of experimentation and testing, but life sucks, hackers suck, security sucks, and we all learn to live with it.

Finally, not related to security, but relevant to the current discussion: the Insteon protocol had a good run, but failed to effectively deal with modern high-efficiency electrical devices.  Insteon assumed a relatively quiet electrical signal, one that can be described as generally a sine wave with a distinct zero-crossing point -- and switching power supplies mess that assumption up totally.  I expect the protocol could be modified to accomodate the current harsh reality of the electrical signal.  But if one had to modify the electrical characteristics, the timing, the speed (so that security could be added), well, then one has to wonder if it's really worth modifying the protocol instead of doing something else.

As for what else could be done -- just a thought, switch to z-wave for the protocol but keep the excellent tactile feel and the KPLs.  If there are any patents associated with scenes and linking, perhaps bringing that to to those in charge of the z-wave protocol for a future protocol revision might be useful in fixing some of the painful parts of the z-wave protocol.

Random thoughts, which matter naught because smarthome doesn't listen to any of us!

  • Like 2
Posted
59 minutes ago, asbril said:

Michel

I was joking and I don't think that it would be worth your time, though it would certainly be beneficial for Smarthome/labs.

As you know I dropped Insteon 7 years ago and I follow these discussions, on the future of Insteon, with some bewilderment.

I think you mentioned it in another thread but remind us again what you went to in place of Insteon because many of us are struggling to find an alternative. Lutron is too limited in their variety of devices  and as soon as you want to do anything much beyond dim groups of lights or control blinds it kind of runs out of steam. The Z-Wave protocol is unreasonably complex and still struggles with implementing basic functions; for example the new Zooz scene controller works OK as a scene controller but if you want to use the buttons for something else you have to do some serious scripting to keep the buttons and LEDs in sync. (If you're going to devote that much time to setting up a consumer device you might as well just run Home Assistant, write 4 pages of yaml code and use Tasmota to flash your hardware with custom firmware!) Zigbee has no local association options so the controller is a single point of failure, LoRa has no controllers that offer a local UI that I am aware of, and nobody has yet invented a Home or Small business router that could support a heavily automated home in addition to running PCs, multiple 4K TVs, and lots voice assistants without melting.

So what did you jump to?

Posted
35 minutes ago, upstatemike said:

I think you mentioned it in another thread but remind us again what you went to in place of Insteon because many of us are struggling to find an alternative. Lutron is too limited in their variety of devices  and as soon as you want to do anything much beyond dim groups of lights or control blinds it kind of runs out of steam. The Z-Wave protocol is unreasonably complex and still struggles with implementing basic functions; for example the new Zooz scene controller works OK as a scene controller but if you want to use the buttons for something else you have to do some serious scripting to keep the buttons and LEDs in sync. (If you're going to devote that much time to setting up a consumer device you might as well just run Home Assistant, write 4 pages of yaml code and use Tasmota to flash your hardware with custom firmware!) Zigbee has no local association options so the controller is a single point of failure, LoRa has no controllers that offer a local UI that I am aware of, and nobody has yet invented a Home or Small business router that could support a heavily automated home in addition to running PCs, multiple 4K TVs, and lots voice assistants without melting.

So what did you jump to?

I am 90 % Zwave, with some wifi devices as well.  Between switches, plug-in and curtain control, I probably have some 80 Zwave devices, which provide me with an excellent mesh network. I admit that Zwave is not perfect, but the variety of products works for me.

I make extensive use of ISY programs and of nodeservers, and as mentioned, I am quite happy with my setup.  It is true that reaction time of Zwave can lag sometimes and scenes somehow do not perform well for me, especially when I use them in switches, which is why I prefer programs.

I guess that if I want perfection, then I would go for Control4, but that is expensive and is also dependent on proefssional installer, which takes the fun out for me.

  • Like 1
Posted
19 minutes ago, mwester said:

Regarding importance: it's a market limiter.  There are those who feel security, even on lighting systems, is important.  There are those who will be required to have security (by their landlord, their company, or other organization with authority over the implementation).  In addition, there are areas of automation that require security, moreso than lighting -- for an automation protocol to be viable it really does need to automate locks, and cameras, and other applications where security is simple required.

The common objection is "but I don't care if some hacker starts blinking my lights!"  I don't doubt that -- but not everyone feels that way.  It's the same with your Android device, and your Window computer at home -- many people I know don't have a lock screen enabled, and remain logged in all day long.  You should have the right to link your devices to the controller in a similar "no-security" fashion.  But if the protocol doesn't support security, it's going to be limited.  As an analogy, consider that PC -- fine for an individual, perhaps, to have no lock screen and no strong password, but if no better security was available in Windows then Microsoft would have lost out the entire business marketplace.

Security sucks in general, that's true.  It's always going to suck, just like fumbling for my freakin' car keys in the rain with both arms loaded with groceries sucks.  But just like I'm still going to lock my car in the parking lot, I'm going to live with security on my devices.  It would be nice to be able to selectively disable it, for ease of experimentation and testing, but life sucks, hackers suck, security sucks, and we all learn to live with it.

Finally, not related to security, but relevant to the current discussion: the Insteon protocol had a good run, but failed to effectively deal with modern high-efficiency electrical devices.  Insteon assumed a relatively quiet electrical signal, one that can be described as generally a sine wave with a distinct zero-crossing point -- and switching power supplies mess that assumption up totally.  I expect the protocol could be modified to accomodate the current harsh reality of the electrical signal.  But if one had to modify the electrical characteristics, the timing, the speed (so that security could be added), well, then one has to wonder if it's really worth modifying the protocol instead of doing something else.

As for what else could be done -- just a thought, switch to z-wave for the protocol but keep the excellent tactile feel and the KPLs.  If there are any patents associated with scenes and linking, perhaps bringing that to to those in charge of the z-wave protocol for a future protocol revision might be useful in fixing some of the painful parts of the z-wave protocol.

Random thoughts, which matter naught because smarthome doesn't listen to any of us!

Good points and I don't mind if a new protocol has better security as long as it covers what I consider to be the basics:

-Can reach remote locations on the property such as the lamp post down at end of my driveway, without having to build out a network of intervening devices. Powerline protocols such as Insteon and UPB work well for this. LoRa also has the range to do this but all current interfaces are web based. Z-Wave long range might do it but no products exist yet.

-Should be Broadcast/Repeat/Acknowledge rather than Routed. Routed protocols are way to complex for automation applications. Routed protocols do not scale well as they get overwhelmed by chatter between devices as the network grows. Routed networks claim to be resilient and self healing but in reality they are never implemented in a way that will cause a device to quickly adopt a better route if it can manage to keep functioning with a marginal one. They can also struggle if you rearrange the furniture and end up moving a few key plugin lamp modules that everything was routing through. 

-Should support local associations so things like virtual n-way light switches keep working if the hub/gateway/controller goes down. The associations should work across the system via the broadcast protocol and not be limited to associations between devices that are in range to talk to each other directly.

-Should offer keypad controllers that can be easily configured as scene controllers, virtual switches, status indicators, or generic controls. The notion of creating a keypad device that is just a scene controller or just a room controller is just stupid.

-Should include devices that will actually work to retrofit older homes and not be designed to only function in new construction. That means switches that do not need a neutral wire. Fixture devices to control old pull chain lights, and so on. And switches need to be thinner. Old electrical boxes are very shallow and usually installed in a way that makes it impractical to replace them (especially for an average home owner). 

Posted
2 minutes ago, asbril said:

I am 90 % Zwave, with some wifi devices as well.  Between switches, plug-in and curtain control, I probably have some 80 Zwave devices, which provide me with an excellent mesh network. I admit that Zwave is not perfect, but the variety of products works for me.

I make extensive use of ISY programs and of nodeservers, and as mentioned, I am quite happy with my setup.  It is true that reaction time of Zwave can lag sometimes and scenes somehow do not perform well for me, especially when I use them in switches, which is why I prefer programs.

I guess that if I want perfection, then I would go for Control4, but that is expensive and is also dependent on proefssional installer, which takes the fun out for me.

And it has been pointed out in other threads that professional installers don't want to offer any really fun cool stuff because it represents a potential service/warranty headache for them.

Posted (edited)

Somehow this conversation has a morphed into security.  I just frankly don't see any reason to worry about security on a light switch.  Unless somehow there is a pathway into your LAN.  And there is just no way someone is going to get into my LAN via Insteon.  ISY, yes, but ISY is of course a whole different bird, but there is no way an Insteon device is going to pass data back and froth from my LAN.  And if somehow someone figures out how to do it, the breach would be in ISY.  I do not use Insteon for anything security related, I have a security system.  I don't let Insteon control door locks or GDO's.  I don't let Insteon control any mission critical devices.  You should always use UL security when doing security.  I use Elk and I also have Elk control things like sprinkler valves, water shut offs, pumps, GDO's, and the like.  Insteon controls lights, ceiling fans, it tells me when my washer/dryer are done, and I'm thinking hard, can't think of anything else.  Furthermore, any hack on an Insteon device would need to happen locally.  Seriously, who is going to sneak around outside my house to try and control my lights?  I'm plenty happy with Smartlabs spending their time and money making nicer devices that work better, and not wasting time/money on implementing any security.  And I think SH/SL should steer clear of selling any products for purposes that pose a life or security risk.  I never agreed with them selling the GDO control for example, though it was more of instructions on how to use generic i/o controllers for a GDO.

If security is your concern, then get rid of all the cheap iot HA devices.  If your going to open a back door into your LAN via HA, I'm pretty sure that is where it would happen.

Edited by apostolakisl
Posted
16 minutes ago, apostolakisl said:

I'm plenty happy with Smartlabs spending their time and money making nicer devices that work better, and not wasting time/money on implementing any security. 

I don't think they are wasting time/money implementing anything new at this point, apart from the Nokia stuff which will be shipping any day now. (No really, before the end of the month, really.)

  • Like 1
Posted
40 minutes ago, upstatemike said:

I don't think they are wasting time/money implementing anything new at this point, apart from the Nokia stuff which will be shipping any day now. (No really, before the end of the month, really.)

Insteon may become all meat, but with no potatoes, gravy, or desert available, who will bother to order the meat?

  • Like 2
Posted
15 hours ago, larryllix said:

Insteon may become all meat, but with no potatoes, gravy, or desert available, who will bother to order the meat?

Sometimes after a nice meal, I like to take a stroll and have my desert at a different establishment.  Perhaps one that specializes in desert.  That is the beauty of ISY, the main course and desert get to be served together even when they aren't from the same restaurant.

  • Like 2
Posted
4 minutes ago, apostolakisl said:

Sometimes after a nice meal, I like to take a stroll and have my desert at a different establishment.  Perhaps one that specializes in desert.  That is the beauty of ISY, the main course and desert get to be served together even when they aren't from the same restaurant.

I was hoping not to order raspberry pie elsewhere though. Most of the non-tech users will want to get a complete multi-course meal all in one restaurant. You and I enjoy the variety and scenery. It seems people are insisting we are just a very small picnic group, though.

Posted
49 minutes ago, larryllix said:

I was hoping not to order raspberry pie elsewhere though. Most of the non-tech users will want to get a complete multi-course meal all in one restaurant. You and I enjoy the variety and scenery. It seems people are insisting we are just a very small picnic group, though.

If you mean the PLM, it appears they are not discontinued as a recent post on here from a user who ordered one and received it.  Otherwise, not sure what you are getting at with the rpi.  Fact is, no company will ever make everything you want.  We have more than one restaurant in the world for a reason.  Beauty of ISY is it is like the common seating area in the food court.  You get to mix and match.

Posted

I think the Kickstarter suggestion is perfect.

My batting average is 0.  Three out of three projects have disappeared without a trace.

Fortunately my total "investment" was less than $300.

  • Like 1
Guest
This topic is now closed to further replies.

  • Recently Browsing

    • No registered users viewing this page.
  • Who's Online (See full list)

    • There are no registered users currently online
  • Forum Statistics

    • Total Topics
      37.2k
    • Total Posts
      372.4k
×
×
  • Create New...