Thanks - different page than the one I found, which didn’t include screenshots of the UI for making rules. It sounded easy, but I wanted to see what the UI was like. That is a LOT simpler than on HA - which I think is needlessly complex for rules. (Well, they have scenes, automations, and scripts - they do a lot, but are needlessly complex.)
If it comes up often, then it’s either heavily used and people are working out how to do this or that, but, more likely, it means that there are a lot of issues with it. Most likely the latter.
I had completely forgotten about that issue! With a new “in progress” HA setup, the locks are there, but I haven’t tried using them through HA and they keycodes don’t work. I had completely forgotten the security code issue - so that will solve that issue whether I move to openHAB or not.
The frustrating part is in dealing with the devices that are inside the wall - not fully, but in wall boxes for switches or sconces and so on. We have a unique house, surrounded by woods, so we designed it to feel a bit like a fairytale house. While we don’t have them in yet, eventually we want to use pushbutton switches, as part of making the place look like it’s from an older time. I still have a number of devices to install, but I have most of them here. We decided NOT to go with the flatter and wider switch design, which a lot of the newer Z Wave switches are. So, from the start, it was part of the plan to put all the devices in wall boxes. Now, with the current issues, that’s more of a problem than I thought. It’s surmountable, just a pain. So whatever I can do without opening up wall boxes, even if it takes me a few extra days, is the preferred way to do things.
Thank you! I’ll be checking those links out.
Part of the issue is we live in the boonies. After 5 years here, we FINALLY have a mostly-reliable internet. Things may have changed now, but when I was looking over systems in 2017 and 2018, most commercial systems were persnickety over internet connections. I’ve had to take into account not always being able to count on an internet connection for home automation systems and other things. Now we have Starlink, which works most of the time, but not during heavy rain. (Before that, at one point, we had Viasat, which was so bad that, toward the end of our contract, we’d lose the signal every hour on the half hour for 2 to 20 minutes!) While avoiding privacy issues is a nice plus, I’ve also avoided commercial systems because we can’t count on the internet being up when we want to do something.
For a while I used an ISY994i, but I HATED that - for a commercial system, I remember I was amazed at what I could not do and how glitchy some parts of the UI were… What drove me away from it permanently was when I found I’d have to buy a new device for newer Z Wave devices and that’s when I just went for open source. I know it’s not going to be super-simple, but there’s something to be said for easier to use interfaces.
Just looked that up. I like it, but doesn’t look ready for what I want to do yet - and looks like it’s not supporting Z Wave or Insteon, which means I’d be replacing a lot of devices. I would do that IF I found a system that was worth it.
Generally, we can. The issue is some devices that are in wall boxes that can dim, but that we have only on/off switches. (I mentioned some of that above - it has to do with the style of the house and the look we’re going for.)
It would be unusual for those to be battery powered. You only need to wake up the battery powered devices. Mains powered devices are always listening and can immediately reply to the request for more information about itself.
It’s an alternative to Zwave/Insteon. But unlike these and other related technologies, Matter is not a walled garden that only works with itself and needs a bridge/hub to work with anything else. With any luck, it will largely.replace these technologies meaning a lot less work to support and broader selection of devices that just work.
If it does that, I’ll be looking closely at it, but I won’t be doing a major changeover unless I can reasonably believe that I wouldn’t be replacing everything in another few years.
It has the backing of the Apple, Amazon, Google, Silicon Labs (who owns both Zigbee and Zwave) along with some twenty other companies. It’s FOSS so no one company owns it and no one company can control it (though certification and continued development of the standard will be done through the CSA, not sure what the cost of certification would be).
As a result, devices that use Matter will work with Google Nest Hubs, Amazon Alexa, Apple’s Homekit, Samsung’s SmartThings and others out of the box. That will encourage device makers to support it since they can implement it once and support all the major commercial platforms.
The wireless is based on BTL, WiFi, and Thread which itself is built on Zigbee. This means that most of these hub devices already have support for the hardware aspect of the technology so most users already invested in these ecosystems won’t have to suddenly go buy a new hub.
Because it’s a FOSS standard and reference implementation, we should be able to make OH a hub itself (with support of a USB antenna similar to how Zwave works). This also means if a company folds (see the recent fun with Insteon) users won’t be completely out of luck.
For these reasons we here are optimistic about this technology and expect in the next few years or so to see a great rush by device makers to adopt it. It’s the first time that the big players in this space have seriously tried to address the fragmentation problem.
But that doesn’t mean anyone is advocating replacing stuff that already exists and already works, unless there is some new device that works better or does something else you want.
I had no idea both were owned by the same company.
One reason I used Z Wave is because I saw that a number of manufacturers were using it. While I didn’t check if it was an open standard, I did see that a lot of companies were using it. I remember dealing with a few people who told me that Insteon was great and had reasons like, “They make it all, so there are no compatibility issues.” I said, “And if that ONE company goes out of business, what happens?” Interesting I haven’t heard them talking about that issue now…
I also remember Sears having something they were trying to start. (Was it Sears? Pretty sure it was.) Lowe’s also had a system, but I never saw anything from the Lowe’s system for sale or advertised anywhere but Lowe’s, so there was no way I was going to go with that one. I also remember Google going with something else before Nest, don’t remember what it was, but then they bricked all those devices and moved on. While that happened after I made my decision to focus on Z Wave, it’s exactly what I was intentionally avoiding.
Open standards are, from my view, the best situation, since developers and users know it can’t be just erased or pulled from the market on a whim or in favor of a different system.
I do have Insteon devices. At the time Aeotec was working on a Z Wave fan controller, but didn’t have one. If I remember, they did release it later, but then took it off the market. At the time the only fan controllers that could do what I wanted were Insteon. (And a few years later, when I was about to install them, I called Insteon and found the original information I had been given - that one controller could handle 2 fans - was wrong. The guy I was talking to didn’t seem to care that I had been given misinformation and had planned out my system and now had to redo things because of that.)
Have you seen indications of anyone working on hubs for Z Wave or Insteon that would work with Matter/Thread? Or some kind of bridge to allow that?
Yes - one big thing I LOVE about FOSS!
I wasn’t surprised to see Insteon go under. I had problems getting information from them (as noted above) and found their attitude frustrating. It’s as if they weren’t aware there were other systems available and that anyone would need to do things they didn’t cover or that their system wasn’t a home automation panacea. I was not overly impressed by Insteon.
I was looking at Homekit as a possible option and when I searched, I saw there was an Insteon bridge for Homekit, and my search actually took me to the Insteon domain where they have a shop. I had been told the domain was out of service and they were 100% dead in the water. Any idea what happened after that? Are they selling off inventory as part of a bankruptcy process or something like that? (I’d love to be able to replace ALL Insteon devices, but that’s not always an option.)
It sounds like something good - and, as I mentioned, if there are bridges so I could use it with my current devices, that’d be wonderful.
It didn’t start that way. SI Labs acquired the Zigbee Alliance a few years ago, or maybe it was the other way around.
Unfortunately it’s not. The original OH binding had to be built through reverse engineering. They eventually published their API but there are some shenanigans going on with the latest version of Zwave and access to the API.
Lowes did indeed release a system and sold devices and hubs for a few years. I think it was called something like Iris.
Ikea has their Tradfri system (which is mostly Zigbee based) but Ikea is among the members of the CSA so I expect they too will move to Matter when the time comes.
There’s a varied history with Google. Technology wise Google had Wave which I think has largely been dropped (nothing but a few Google devices used it anyway) and Google actually developed Thread with the Zigbee Alliance which Matter will be based on. They bought Revolv (I think that was the name) but it seems clear it was always a purchase to obtain patents and technology, not to keep the product line going. So they shut it down and because it required Internet, it bricked all those devices.
It’s a lesson most of us have learned more than once. If it requires an Internet service to work, you don’t own the device.
Zwave isn’t a bad choice really. It’s usually quite a bit more expensive than alternatives but it’s a mature technology with a lot of choices and not dependency on the cloud. But, in the future I’m not sure I’d recommend it quite as strongly. The good thing about a system like OH (and HA for that matter) is you are not locked in. If you replace one of those Zwave switches with a Shelly 1 or Shelly 2 it’s no big deal. You are not stuck with Insteon and Zwave forever and you are not stuck with only those two technologies. You have the ability to choose what fits best, even if that means introducing a new technology.
That’s too bad. I’ve been half keeping my eye open for a good ceiling fan controller that works with OH.
Depends on what you mean by “hubs”. The big Amazon Alexa already supports Zwave I think (but then OH can’t really use them) as does SmartThings and others. I’d expect Hue to move to Matter at some point (it’s already Zigbee(ish) so it’s not a big lift).
But if you mean USB transceivers that OH would locally interact with, Sonoff looks like they are moving in that direction already (see ITead’s “Sonoff Zigbee 3.0 USB Dongle Plus” (model “ZBDongle-E”) based on Silicon Labs EFR32MG21 +20dBm radio MCU now sold for $19.99). I expect Aeotech and others will follow suit. But I’m not sure what sort of API these USB sticks will support. Will it be defined like Zwave so any controller from any manufacturer works, or does each vender have their own API similar to how Zigbee works today.
Ideally, we want OH to be the hub, or at least the software behind the hub so the USB dongle approach is what we would be looking for the most I think. But it’s the support of Google Hub, Alexa, and Homekit that will drive the industry at large to use Thread and create devices that use it.
Long story short, the company just shut off the lights and closed down without warning. The C level execs wiped Insteon from their LinkedIn profiles and everything. I think the company then went into receivership and a new group of investors either bought the company outright or bought the tech and resurrected the company. So there was a couple weeks of “no more Insteon” and now we have “back under new management”.
The new owners seem to understand a bit better what they got and what it will take to keep it going.
That’s sort of the raison d’être of openHAB. openHAB is your bridge. It consolidates all the sensor readings and all the actuators so, based on any event (e.g. a temperature change) it can issue a command (e.g. turn off the AC). Once it’s connected to OH, it doesn’t matter if the thermometer is Insteon and the thermostat is Zwave.
Thread is an evolution of Zigbee, and I agree that it’s not ready (it’s not even officially released). The way I see it, there’s no need to replace existing devices, but my hope is that going forward it will present as the no-brainer option.
Matter will theoretically enable your existing devices to interconnect with less trouble, whether they’re old devices or newer WiFi/Thread devices. Some existing smart devices (e.g. Google’s Nest Hub v2) already have Thread radios and will be upgraded to serve as “border routers”.
I don’t know enough about the technical side, but I suspect it’ll become one of two things for OH/HA/etc.:
Connect to a border router to get its devices and then issue commands through it.
Get a Thread USB controller (if such a thing exists) and act as a border router.
These are just guesses, since I’m not capable of doing any of the development work.
Whatever the case, that’s the future, not the present.
Your flaky Internet is, in my opinion, the primary reason to avoid cloud-based systems. Privacy and security concerns vary for different people, but flaky Internet is flaky Internet.
I’ve settled on mostly using TP-Link Kasa WiFi switches, mostly because they’re cheap and also because OH can control them locally. However, they won’t work for you due to an aesthetic that is more more space-age than rustic. Of course, if you need an excuse to get a 3D printer, you could make your own covers for them.
If you’ve noticed, I couldn’t remember that name or Revolv - which I’m pretty sure is the one I read about that I linked with Google. When I look into something and rule it out for what I want, I tend to forget the details - at that point they’re not that relevant to me anymore. I get that Google wanted the Revolv patents, but, still, that whole thing of abandoning the customers is a red flag to me.
That’s one reason I am using HA now and trying to decide between HA and oH for the future.
Side note, I have a ZWaveJS2MQTT (I can never remember the full term for that one!) in our barn controlling only ZWave. Right now it’s alive, but not connected to my old, failing HA install or the new testing one. (And the old HA install on a Pi is weird - it’s still controlling Insteon devices, but it’s NOT on my LAN. I’ve checked DHCP leases and looked at the console on a monitor on that Pi - it’s not where it thinks it is and not where the DHCP server is supposed to assign it and not on any other IP address!) If it were possible for HA and oH to talk, it might make sense to set up oH in the barn for those devices. Both buildings are on the same LAN (different wifi nodes, but one LAN, connected with fiber optics from one building to the other), so I could actually use HA and oH and test oH out that way. I suppose there’s no way to make one system a secondary hub to the other, though. (This idea just occurred to me - so writing it here was part of thinking out what I could do.)
I’m not as worried about price as I am about performance. Not that I’ll throw money away, but I have found ZWave works. Why would you not recommend it as strongly in the future? Because you expect Matter to take over?
That’s one reason I like FOSS! I mentioned I had an ISY994i - still have two of them. Not going back because there were several things about it that were a pain to deal with and HA (and oH, from what I see) work better, overall. What I did like about the ISY originally was that I could use it for both Insteon and ZWave.
I think there were issues Aeotec was concerned about. I can’t remember if it was leading edge vs. trialing edge (I think thaw as more of a dimmer issue) or something about trying to handle an AC motor. I was disappointed when I looked at it months later and the beta version (or new version?) was gone. I think it was a variable device that could be used for dimmers or fans and wasn’t working for fans. I don’t remember the details.
Right now I have multiple Insteon fan controllers I’ll be using in my house. I bought them just after construction and still, after almost 5 years, haven’t had time to put them in. (I’ve been doing things like building a road to the barn, renovating the barn, and more - home automation is a priority, but not a “I have to do this before the permits expire” kind of thing.) I figure, since I don’t use Insteon’s services and just devices, it doesn’t matter if they’re bankrupt or resurrected or what.
I’m not eager to give Amazon that much power over my home. First, I suspect it’ll need a continually working internet connection, and, second, I’m just waiting for them to start charging monthly for something like that. I’m not paranoid about every big company, but there are ways I trust some companies and not others. Before the Revolv thing, I would have considered Google and Nest. Now I might look more into Homekit, since there are ways I can use that with various systems.
I think best to break my question down in 2 parts - I was not clear. My bad!
If I started using Matter (when it’s released), would I be able to use it to control my ZWave and insteon devices? Maybe through the USB dongles or some other way?
Would it be possible to do what that (in #1) by having using an oH system that controls my Insteon and ZWave devices and then have that oH system controlled by Matter? (I’m figuring this is all still hypothetical at this point.)
Okay, that clarification helped. I did know about the execs wiping it from their profiles and it just vanishing, so I was surprised when I saw the domain was still there. I wish the new investors well - especially if they improve a few things. (I’ve had problems, for instance, with my garage door opener. I have an Insteon modem/relay plugged into an AC outlet 4’ from the USB PLM. The garage door opener is on the other side of a normal stud wall with drywall and about 15-20’ out from the wall. The PLM frequently loses contact with that device. I had other problems with poor wireless transmission with Insteon, with it not able to control devices in the same room as the PLM.)
That brings up something I’m looking into - I’ve asked on the Home Assistant forum about it (still no answer) and I’ll probably post a question about it here. I have an Insteon Dimmer Micro Module. It goes in a wall box and hooks up to the wall switch and light circuit. When I flip the switch, it turns the light on and off. With oH, can I use that flip of the switch as a trigger for a rule? And are there ways to store variables from other rules? (So, for instance, I can set Night_Flag to True at 15 minutes before sunset and false at 15 minutes after sunrise. Then when that switch is flipped, if Night_Flag == True, the light would only go on 30%, otherwise it’d go on to 100%.)
If that’s better as a separate thread, I can post it as another question.
That would be nice. I’m sure I’m only one of many, many people that would like that!
It’s better now than what we’ve had. It’s predictable. Storms can sometimes block it, but on the other hand, for rural internet, we FINALLY have no data caps or bandwidth issues. Last month was the first time since we moved here (and I dumped satellite TV) I could watch the entire Tour de France through streaming and not even care about bandwidth!
But, even with that experience, living here has taught me to never count on the internet always being there. Privacy - there are some companies I trust more than others.
Also one other point: We have a standby generator, so it’s quite possible we would have the entire house and barn with AC power and NOT have internet for the duration of a storm or because there’s a problem providing power to the dish (which is 900’ from the house!). That’s another reason I’ve learned not to count on internet. Even if we got a wired connection, it could be out when we’re using the generator.
I’ll look into those. The interesting thing about buying a 3D printer is that it doesn’t take long before you start finding tons of things you can print to fix things or make them work better. For instance, I bought two small elbow lamps for my workshop, one to keep a light on the printers (so I can watch them with OctoPrint) when the shop lights are off. The design was stupid - half the light bulb sticks out below their small shades. I was thinking, “Have to send them back - no, wait…Yes. I can print extension lampshades for them.” And I did. I’m getting used to that.
(By the way, the printers, CNC, and laser on the CNC, are all for a new business, so it’s not just fun!)
Yes absolutely. The rule / scripting / automation capabilities you get with openhab is virtually unlimited - no different to a stand alone program that you could create.
An easier way that I do this is using the sun elevation. I have an item that tracks the current sun elevation (it’s measured in degrees above the horizon - so after sunset the sun elevation is negative), and in my rule, example pseudocode:
if Sun_Elevation < 10 then
Set Light_Dimmer to 30%
else
Set Light_Dimmer to 100%
end
If you want this 10 threshold to be configurable and global across your entire system, just use a “virtual item” that holds it, e.g. Sun_Elevation_Threshold. Set it to 10 on startup and use its value for your comparisons in all your rules.
If someone makes a Thread USB dongle, it’ll be possible for OH to serve as a border router. However, I think it might end up being simpler than that, since Amazon/Google/Apple/others are planning to turn their existing hub devices into border routers that can issue commands locally without Internet. OH might be able to just piggyback on a Nest Hub or Amazon Echo.
We can actually already do this with an Echo using the Amazon Echo Control Binding, but there are limitations due to the polling rate. I’m hopeful that Matter will enable something that’s similar but better.
I think this would require OH to identify itself as a border router. So yes, it’s possible, but I’ve no idea what it would take to make it happen. Again, we already have something similar, as OH can make devices appear to be Philips Hue bulbs/switches, or share them with Google Assistant and Amazon Alexa (though that requires the myopenHAB cloud). I’m not sure about HomeKit, as I don’t use it.
Saying that, I think it’s best to do the heavy lifting on automation with OH or HA, and then only share out the devices that you want/need to control through other interfaces. For example, I only have about eight of my devices available in Google Assistant, because they’re the only ones I operate with voice commands.
Yes to all of this. Any state change can be used as a trigger, and many of us use virtual items in OH as variables. I have some that are on/off switches and some that are strings or numbers, depending on the purpose. As for the Night_Flag based on sunrise/sunset, that’s easy to do with the Astro binding.
In my opinion, simple connectivity is the stumbling block for home automation. That’s often the case with technology. Think about how difficult it was to set up a home theatre in the period just before HDMI gained acceptance, when your TV had three different types of video inputs (and three for audio), while your DVD player and cable box each had one or two of the corresponding outputs and your receiver had 20 ports on the back that mostly looked the same. Home automation is going through that right now.
I tell people that my 3D-printing hobby is 50% designing/printing things, 25% fixing my printer, and 25% upgrading my printer (often by designing/printing things). I recently spent an evening designing and printing TPU sound dampeners for a mechanical keypad I bought from Amazon, then sent the keypad back anyway due to other issues. I have no regrets.
FYI, unlike Z-Wave (for which is only one protocol stack since there is only one manufacturer), all Zigbee stacks application firmware use their own proprietary API/CLI, and Silicon Labs Zigbee Stack is named “EmberZNet Zigbee” and Silabs API/CLI for it is called “EZSP” (short for “EmberZNet Serial Protocol”).
The Zigbee API/CLI for different Zigbee stacks are however fortunatly all those are proprietary APIs/CLIs are still somewhat similar to each other and since Zigbee is standardized it is possible for the Zigbee library that your Zigbee implementation use to write hardware abstraction layers for each Zigbee stack API/CLI to allow them to support multiple Zigbee stacks and as such different Zigbee SoC hardware adapers/dongles, and that is what many open source Zigbee implementation libraries have done to workaround this, see example these which have modules or adapters for each Zigbee stack API/CLI:
Note that the SoC hardware for Zigbee can support several different protocols based on the IEEE 802.15.4 specification, though they usually only support one protocol at a tim via different firmware.
You should be able to bridge between the two using MQTT. There is another HA thread here talking about doing that. OH recognizes and automatically discovers HA standard MQTT.
Because SI Labs is requiring the user of their proprietary API library to support the new standard for Zwave. Obviously, such a library cannot be included in an EPL licensed project. So I’m not optimistic that Zwave will remain a FOSS friendly option.
Also, at least for me, the cost/performance calculation does not come out in favor of Zwave when compared to Zigbee.
No, they are completely different technologies. A Matter hub wouldn’t be able to communicate with anything except Matter. But that doesn’t mean there can’t be hubs that speak Matter, Zwave, and Insteon.
Yes, that’s what OH is all about. Bridging between technologies. You might need three separate USB dongles, one for each, but once OH is talking to them it will bridge between them.
Almost certainly yes, assuming Insteon reports it’s been manually switched.
The devil’s in the details. On general you’re best off using a separate Item to store that value. Otherwise the answer is “it depends”.
You would use a Switch Item linked to an Astro sunset Channel with an offset and perhaps an Expire on the Item to switch it off after 30 minutes. Then your rule that runs to set the dimmer would check that Item.
Snapmaker is a 3-in-one that I mainly got for the CNC but have only used the 3d printer mode this far printing parts and tools and such. But if slave is your concern, you can get all three in one device.
I love the idea of the Snapmaker, but it’s more than my budget will allow. I’m glad to see them doing well, though. I remember seeing the original Kickstarter and thinking that the concept was smart.
I dunno, Rich. Sci-fi movies featuring robot slaves always start right before the robot uprising or right after the robot victory. If my openHAB server gains sentience, I’d rather that it doesn’t have control over an actual laser.
First, I seriously appreciate all the information everyone is including in this thread. I think I’m learning more than I’ve learned from any question I’ve asked in a forum in decades - and that dates back to the WWIV BBSs in the early 1990s! Thank you!
At this point I have managed to transfer my Insteon PLM to my new Home Assistant system (on a Pi4) and I was glad to see all the devices carried over. That’s a relief and tells me they’ll likely carry over when I add them to an oH system as well. I’ve been looking over the manuals on rules and the screen shots. I do NOT want to try to make this a competition between HA and oH. I love FOSS and I think the community benefits from having more than one project for a particular purpose. (And I have seen projects that can be in one field that actually use code from each other, but still have different theories on how to do things. Hey - if it works, great!) I think HA is a good system that is the result of a lot of work, but after looking over just the one topic (rules) as an example and comparison, I will likely be switching everything over to oH within the next few months.
A lot of this is personal. I feel like I struggle to get things done in HA and what I’ve seen in oH it feels like the interface and the way it works is closer to the way I think things through than HA. Again, not saying HA is bad - just that from what I see, it looks like I think more like oH does.
Interesting way to do it. so if the elevation is 0, how do I distinguish between whether it’s sunrise or sunset? And, on this topic, is elevation the only way to do this, or is there a way to specify time since or until sunrise or sunset?
I’m not fully clear on the term “border router.” I’m thinking that’s basically a device that stands between one system and another to allow an interface between the two?
I had not even thought of a mix like that, but I can see the advantages. Sounds like a good way to use the strengths of each system.
Sounds like a system I could easily get used to and work with!
One reason I was thinking about a flag like Night_Flag was because I had something a little more complex than my original idea in mind. I was thinking that during the day, the switch on the hall lights would go from off to 100%. But then, starting 15 minutes before Sunset and after Sunrise, it’d work differently. It’d follow a pattern: off->30%->100%->off. So during that time, it wouldn’t be just off/on, but would have 3 steps, like a ceiling fan that goes from one speed to the next each time you pull the string.
(Actually, side note, we have a great room that is overlooked by galley/promenade on the 2nd floor - which is in place of a hallway. The stairs are in that same large space. The lights I’m talking about are in that area and turning them to 30% at night is a nice night-level illumination for that entire space.)
I remember it well. Not with fondness, but well! I also remember at one point, when I wanted to split video coming out of the cable box so it’d play in the living room and in my study, what a nightmare it was mixing newer components that were HDMI with older ones using RCA cables.
I think the issue would mean using either wireless or sending a signal over the power line in the house, since I can’t see adding another set of wires going everywhere. But from what I’m reading on this thread, I’m thinking that if Matter/Thread works, a lot of systems would use plain wifi. It’s easy, already exists, and there would be a lot of flexibility there.
I see you’re using an Ender. I got one in February, but also a CR-Touch. Took me 5 months before I could print - turns out there’s a nasty little bug in Marlin for the GD chips Creality switched to around February, when I bought my system. Finally got it working, but, in the meanwhile, bought a Prusa. The two behave dramatically differently!
I’m working on prototyping for things I’ll be printing. My long range goal is to develop the prototypes here and eventually work with a company that can produce my produce on a larger scale, so, ultimately, I won’t be printing massive amounts of product.
The CNC - well, some of the same, but with the laser, I’ll be making signs and doing other work, too.
Nice!
I just added a 2nd webcam to my OctoPi system, but it’s misbehaving. I know, with plugins, I can control both printers with one OctoPi system. That’s my goal. I have an order in for a cage for the Prusa, but they’re not shipping yet. I may just make a cage that goes over the entire table instead of waiting for it. (Since the printers and the CNC are in the same room, along with a drill press and table saw, I want to make sure the printers are kept contained so sawdust isn’t an issue for them.)
This is part of our (mine and my wife’s) lifetime dream. While we’ve only been together 10-12 years, both of us have wanted to live out in the woods for all our lives. So we got it - a 24 acre lot, mostly wooded, with a house that has a bit of a fantasy feel to it, and we renovated the old pig barn that was here before us. That has a workshop for me and a studio for her creative work. Like I said, it’s a lifelong dream, something we’ve both been working towards on our own for decades.
Doesn’t that create a serious mess with devices having different functions and features? Maybe I’m misunderstanding it, but it shoulds like you could have lights from different manufacturers that work differently.
I love it when I’m learning something new, but there are people ahead of me to guide me. That sounds like a great way to do it until I reach the point where I want to unify it all. But there are also the notes I made at the start of this post. The more I look at oH, the more it seems that my work flow and style are more like oH than HA.
Side note: Currently I have an MQTT server in the barn that uses the HA as a broker and the HA instance can (or could, before it started dying after a thunderstorm) control everything in the barn through MQTT. But I’ve had people tell me there are issues with ZWaveJS2MQTT and HA having problems if one updates before the other. That’s what’s made me think that whether I use HA or oH (and I’ve decided to switch to oH after I’ve had more study time and can plan it out), I think I’d rather have two instances of the same type of system, with one in charge. It’s one less package to learn and keep track of.
I see. I would think that there are people who would keep things going so those of us with Z-wave devices aren’t left high and dry. When it starts fading, I’ll make plans for replacing all my Z-Wave devices over time. (Right now I’m more worried about Insteon devices. While I figure most of these things, in either system, will keep working for many years, I feel like I’m tempting fate by continuing to use Insteon now.)
That’d be good for many of us, since it allows preserving systems we have while upgrading to a new one over time, as budget and available work time permits.
I have a friend who loves his Snapmaker. I considered it. It looked pretty good, but I went with Shapeoko for several reasons - and that was over a year ago, so I couldn’t list the reasons if anyone asked! (When I got the CNC, I had not expected to get a 3D printer, too. I find I, too, am using 3D printing much more than CNC - at least at this point.)
If it gets that smart, it’ll figure out how to print out a laser!
There’s a reason I don’t call any of my systems names like Skynet or Landru. It’ll be kind of scary when Apple moves from their M1 and M2 chips and offers M5 computers.
(But I figure I can always pull a Kirk and ask the computer illogical questions until it starts pulling too much power and it lets the smoke out of all its chips!)
In my rules, I don’t really care whether it’s sunset or sunrise because they are simply using the elevation to decide whether to perform something or not. For example:
“if someone turned off the living room light, and it stays off for 10 minutes, and the sun is not visible (elevation < 0), then turn off the wall mounted display screen”.
rule 'Turn off photo frame' do
changed gLivingRoomLights, to: OFF, for: 10.minutes
only_if { Sun_Elevation.negative? }
run { PhotoFrame_Screen.ensure.off }
end
If on the other hand you actually need to run specific tasks on sunset e.g turn lights on 10 minutes before sunset, and turn them off 5 minutes before sunrise, the Astro binding has that covered using offset.
For a task to be performed after the event (sunset/sunrise) you can have your rule fire on the event (so you don’t have to configure the “offset” as per the above link), and then inside your rule, create a timer that will execute the task X minutes later.
Others can probably give you more ideas. If you can describe the exact scenario, we’ll be happy to go into it further.
Most importantly do not hesitate to ask here if you are stuck. We’ve all been there. I am constantly learning new things about openhab.
I would write something like this (in jruby):
# cycles the light from OFF -> 30% -> 100% -> OFF
def cycle_light_level(light)
light << case light
when OFF then 30
when 100 then OFF
else 100
end
end
# Returns a range from sunset to sunrise, minus/plus the given offset
# can be given as argument for TimeOfDay#between?
def sunset_to_sunrise(offset = 0.seconds)
astro = things['astro:sun:home']
pre_sunset = astro.getEventTime('SUN_SET', nil, nil).minus(offset)
post_sunrise = astro.getEventTime('SUN_RISE', nil, nil).plus(offset)
# convert to DateTimeType range
DateTimeType.new(pre_sunset)..DateTimeType.new(post_sunrise)
end
rule 'Hall light switch' do
updated Hall_Switch, to: "click" # assuming this switch sends "click" when it's tapped / clicked
run do
if TimeOfDay.now.between? sunset_to_sunrise(15.minutes)
cycle_light_levels(Hall_Light)
else
Hall_Light << 100
end
end
end
Or you can have two other rules that control Night_Flag and then use Night_Flag in the “Hall light switch” rule as others have suggested above. One thing to consider when using a “Night_Flag” type system: you’ll also need to set this flag when openhab starts up, so you’ll still need to actually obtain the sunset/sunrise time and not just rely on the astro trigger event. This is to cover the time when openhab gets restarted after the set time for night flag, otherwise your rule will run incorrectly until the following day.
This is the way.
If you want to use HABApp (python3) there is also the possibility to use the Scheduler to run a callback.
There you can also chain boundaries, e.g.
There are countless ways how you can achieve your goal and it’s only limited by your time and imagination.
Just try different things and use what suits you best!
Just make sure that you document the location and type of each device by device id. This will make setting up in OH considerably easier. When the Insteon binding finds new devices it adds them to the inbox with the address of the device name based of the address of the device. (device address AA.BB.CC → device name AABBCC).
Since I’m using modules rather than switches for devices in the house, and these modules go in the j-box or wall box (or ceiling box) for a light or fan mount or for a switch, I’m recording the Insteon address for each device before it goes into the wall!
