There are both local and internet based LIFIX protocols: https://lan.developer.lifx.com/docs. I have a few bulbs, but they are not suitable for every light fixture.
Anyone want to guess where automation is going?
- Thread starter Linwood
- Start date
Quixote_1
Active Member
I've found the LAN reliability to be extremely flakey. Another drawback is that they are often unresponsive when the network has heavy traffic. I only have a 15Mbps connection, so when downloading torrents or streaming video I find the response times unacceptable, if they respond at all. Even still, I've grown very fond of them and I'm sure that if I took the time to configure my router properly I could avoid that problem.
upstatemike
Senior Member
I wish Lifx or some multi-color LED bulb company would make a wall switch controller so you can operate them without using a phone app (app based control just doesn't cut it with my family). I'm talking something that will fit into a standard decora wall plate... not that monstrosity that HUE offers.
We have 3 lifix color bulbs. They are mostly controlled by automation rules, but they can also be controlled from a 4 button centralite switch, top button for on/off/dim, the three other buttons are for "dimming" the RGB. Initially kids played with the buttons, but now they are rarely used as the automation does a good job on its own.
Quixote_1
Active Member
Once Mi Casa Verde finally gets their sh!t together and implements the Aeon Wallmote Quad with full functionality, that looks like our best bet for the most complete control option. Until then, I have to agree with Picta that automation is the best use for these bulbs. I really enjoy the ability to be alerted to emails, texts and calls through flashing lights because I never fail to notice the notifications, even when listening to loud music or working with noisy power tools.
I use two inputs for daily temp. The first is pretty simple, I just measure the outside temp 30 minutes before sunrise. That gives a very accurate guide of how hot it will be. Second, I have a Raspberry Pi that gets the weather forcast and gives it to the Omni with a serial connection.dementeddigital said:
Well insulated? Our rates go up from noon to 7 pm so that is 7 hours. We tried to include lots of granite and tile mass, so I think that is more important than insulation. We're usually fine up to 115. Over that it may kick on the AC if it gets over 84 inside. Our electric rate charges us $11 for every kW peak ANYTIME during the high times, so if the AC runs, its limited to about 20 minutes but typically doesn't go over 15.
Yup, all Omni programming, except for a very small amount done in the Raspberry Pi.
Ano that is super cool! What software are you using to do all that work? I didn't think the programming area of the Omni was really capable of all that?
Transferability is a problem. In my area there is hardly anyone who commercially supports HAI products which is a shame because I love them and they are super affordable and in my opinion competes with the big boys!
Transferability is a problem. In my area there is hardly anyone who commercially supports HAI products which is a shame because I love them and they are super affordable and in my opinion competes with the big boys!
I didn't realize there is a time of day usage but there is one here as well. Turns out that it is seasonal (I live in S Florida) so everything here is seasonal. This is valuable information. I might adjust my thermostat programs to work differently with this information!
Thanks for the help and I am curious to learn more about your setup. Perhaps you could start a new thread about it since it sounds complex?
Thanks for the help and I am curious to learn more about your setup. Perhaps you could start a new thread about it since it sounds complex?
WiFi home automation/remote control sound great, easy to implement, and control. It is, so far.I have a dozen or so devices that use WiFi to remote control.
However I don't want my HA/RC devices to share a channel with a streaming 40GByte movie while crossloading a 30GByte file copying through a gigabit router or switch channel or cable.
Neither do I want my microCPU bound HA devices sifting through all that data only to look for it's IP address inside gigabytes of other device's noise.
WiFi channels start to bog down with overhead when the device count gets too high. The maximums are not what you set in your router's DHCP allowance.
However I don't want my HA/RC devices to share a channel with a streaming 40GByte movie while crossloading a 30GByte file copying through a gigabit router or switch channel or cable.
Neither do I want my microCPU bound HA devices sifting through all that data only to look for it's IP address inside gigabytes of other device's noise.
WiFi channels start to bog down with overhead when the device count gets too high. The maximums are not what you set in your router's DHCP allowance.
Dean Roddey
Senior Member
Wifi is the VHS of home automation. It doesn't win because it's a better solution, it wins because it's already there and so the person making the (so called) smart device doesn't have to create any sort of communications technology, or commit to one that he'd have to license, or create any sort of 'system'. He can just put a freebie web server in it, provide a REST API, and that's it. So everything ends up using the lan/wifi by default, though it's clear at this point that it's not really designed for the coming mass of all these small devices, and that the lack of security on the part of the makers of them means that they are dangerous to the things that are appropriately on the lan/wifi.
Software that would be used to implement such a system is referred to as middleware. It is the common denominator between external devices and the HAI controller. The middleware would get the weather forecast data, process this data and send thermostat commands to the controller based on the evaluation of this data. Unfortunately, you just cannot send any type of variable data to the controller and allow it to somehow "crunch" this data and make thermostat control decisions. The reason being is that the serial protocol, more specifically Omni Link Protocol Rev 2.12 does not have any mechanism for sending any type of variable data to the controller. Thus, the need for middleware.heffneil said:
A good example of this type of application is jommnlink https://github.com/digitaldan/jomnilink
Similar threads
