If you automate your garden irrigation, make sure that the valves close even if openHAB is down or if there’s an error in your rule
If you automate your garden irrigation, make sure that you calculate the moisture correct. (i tried to irrigate my plants to 400% due to a calculation error, which i’ve realized in the evening). (See first note)
If you automate your garden, check your body for ticks aftwerwards
The day after you’ve automated your garden irrigation: DON’T BE SO STUPID TO WEAR THE TICK INFECTED SHIRT FROM THE DAY BEFORE!
Haha, when I left school Google and the Internet weren’t even on the horizon. I was learning code on a BBC model A doing BASIC. We also have an older Apple II that was used for various tasks. So if you didn’t understand something you had to either hope the teacher knew the answer or one of your class mates. A last resort was to pickup the reference book and try to find a good example.
I was going to but that idea was already covered and I mainly wanted to add rather than rehash what had already been said. There is a lot of great advice in this thread.
There is a few more things I’d like to add which is more of that I wish other users would learn before posting for help on the forum.
Show your work: tell us what you’ve done, otherwise we have to assume you didn’t do it and we all waist time
Don’t redact: the XY Problem is real, don’t try to make things easier for us by removing things from your code or the logs; we are all very good at filtering out the irrelevant ourselves
Tell us your end goal, not just asking how to implement a solution to get to your end goal: again the XY Problem, for example instead of “how to I implement a lock to prevent two rules from running at the same time” ask something like “how do I prevent this Timer from being cancelled when another rule is running?”. The first presumes a solution and likely a poor solution (don’t use locks) but the second is open to solutions you may not have even thought of yet.
These are called edge cases. In typical programming well more than half of your code is to handle these edge cases. This is definitely an important lesson.
Pretty much the same only Pascal on PC Jrs. Though I had only learned TI-Basic at home on an old TI-99 at that point. I actually had to campaign to get enough fellow students to sign up for the class to make. Even though it was old, Pascal was a good teaching language. I was well prepared for C++ when I got to college (1995).
It’s way easier to get started now. Even my 8-year-old is making games and such with Scratch (shhhh don’t tell him he’s learning programming).
Regarding experience with proprietary gateways and cloud services - it sounds like providing they are fairly simple devices, the ‘preferred direction’ (born from bitter experience ) is to find someway to connect whatever devices you have to MQTT (e.g. using tasmota etc), then to HAB, then go from there. Is that right? Of course, that doesn’t work so well for devices that use significant processing in the cloud e.g. voice recognition, image processing.
I don’t think the rule is quite so simple. Some technologies lend themselves to direct control by design (Zwave, Zigbee, KNX, etc.). Some device provide an open local API to interact with the devices out of the box (Sonoff(?), Shelly, DIY of course). Some devices/technologies have a reverse engineered API to allow for local access (Govee, though calling it “reverse engineering” for publicly broadcast BT packets may be too strong a term). Many devices will be based on an ESP chip. In those cases when the vendor doesn’t supply a local control API (or any API at all) an option is to flash the device with an alternative firmware. And in some cases, cloud APIs are and probably will remain the only viable options.
You just have to do a little research and you have to decide where you limits are. Some people won’t use a cloud based API ever. Others are OH with it. Some are afraid to try to flash new firmware onto a device, and not without reason as I’ve bricked a couple of Sonoffs trying to do so myself. So set your limits and choose what fits inside those limits.
Many devices that are MQTT “compliant” are not really at the device level. The use of their cloud service is still required. Behind the scenes it might work, but if the cloud service is shut down, you are back to owning a door stop. Also many are done by reverse engineering the protocol, something that can break the second the company makes a change to the product. Govee for example doesn’t use a published API, they just kinda splatter unencrypted bluetooth commands out from your phone/hub. This is likely something Govee will change in future due to security and performance issues. I would expect the product to change as the company gets more popular, and if they don’t provide an official API or endpoint I can see these devices suddenly being dead for our uses.
In my case it was a combination of not RTFM and going through an “upgrade all the things!” I noticed that the Tasmota running on these was really old. Instead of following the advice on Tasmota’s site to don’t fix what isn’t broken I decided to upgrade. But I didn’t read the release notes and I tried to jump forward too far which was explicitly mentioned not to do.
So it was totally my own fault. I did try to solder some wires to it and reprogram it that way but my programmer broke too. In the end I gave up and got some Peanut Plugs (Zigbee) instead.
Lots of good stuff here.
Something I would like to add is that you should strive to test your rules.
Add testswitches which trigger your rule and an or statement to your trigger for the test switch add the testswitch with a group to your admin part of the sitemap.
Use Karaf console to change item values in order to test your rules
Use logging wisely, don’t logg too much but still you need to know what is going on
Keep your rules as simple as possible, if you have pages of logic in one rule, it’s probably not a good idea, and a lot harder to test them.
You can trigger rules to run directly though MainUI. However, if you depend on event.itemName or the like that won’t work so you will need to use a test Item to trigger the rule, though a Switch is not always the right choice depending on what the rule does with event.itemName. Often creating a new Item is not required and you can just update or command the Item that already triggers the rule.
In addition to the Karaf Console, MainUI has a developer sidebar where you can search for, pin, and interact with Items. You can usually use that to send commands or change Items without needing to resort to the Karaf Console. If the default card shown for an Item doesn’t support the interaction you need, you can override that by setting the “default cell widget” metadata for the Item to allow for control.
Another option is to use the REST API to update or command an Item.
Yet another approach is to use the --Scratchpad-- Script which can be created and accessed from the Developer sidebar or from the Scripts menu. You can write pretty much any code that can be a part of a rule here and then run it. This is a great way to generate a test that requires a timed sequence of events. Of course, you can also create your own Scripts and create tests that you want to keep around as the --Scratchpad-- is mostly just for temporary stuff.
Use logging levels to help control what gets logged. If you use a unique logger name per rule or related group of rules then you can put a lot of the testing and information log statements at the debug level. When working on those rules change the logging config to DEBUG just for that logger. When done move the level back to INFO and all that noise will go away.
@rlkoshak
I agree with everything you wrote. I find switches to test some rules useful, as I can keep them in a testing menu and access them on my phone without hassle.
I also tend to put settings as items. For instance the dim level on zwave/zigbee dimmers. The level of dimming for the cosy lights, the timeout for turning lights off etc. By doing this I can also change them directly on my phone using SetPoints without having to access my computer. I tend to tweak my smart home a lot and it is nifty to be able to experiment with settings.
You get what you pay for.
If things are working fine, don’t upgrade just to upgrade.
If you upgrade and a device fails, it’s going to be the one hidden behind a wall switch in an impossible location. You have been warned.
Install and test only one device at a time.
Think of longevity. It’s better to buy an older well tested and documented device than to buy some new device on kickstarter by some startup that soon disappears.
Avoid 433MHz devices due to interference from nearby devices causing commands to be missed.
Use multiple WiFi access points in multi floor and larger installations as the range on ESP8266 devices often isn’t that great.
When using SOnOff to turn on anything inductive such as an ebike charger change out the relay for a SSR if you can find one that fits inside the case - I found a 2A Type after the original 16A relay welded. For larger loads use an amplifier inrush current limiter
Don’t expect your new device (Samsung QLED TV in my case) to fully work with existing bindings
Avoid anything in the cloud where possible, its an extra layer of complexity and delay you don’t need.
AliExpress moisture sensors have a finite life, even the capacitive ones.
1-Wire temperature sensors sometimes fail so keep spares.
CAT6 Cable works for most low voltage signals.
Tasmota equipped ESP8266’s need a reboot after a few weeks otherwise random failures creep in
Consider what happens to usability if OpenHAB is down - can things be operated manually by the rest of the household whilst you fix the problem? Does your smart switch still allow the light to be operated if the WiFi is down?
My points do not directly answer the question: “What have you learned that you wish you had known at the start?”
document everything; the less proficient you are, the more to document
Most often I solve a problem and then do not touch OH for 10 plus months… by then I have forgotten all of it, incl. rule DSL.
test things properly, in particular to arrive at a defined state when things fail; e.g. an irrigation valve, which has the potential to waste thousands of litres of water.
use heart beats to ‘emergency’ switch OFF or correct/default states
use something like GitHub to version-control
make regular back-ups, even the most experienced fail to make (and I am talking about the moments where we think we do not need one; that’s when it bites).
some IT architectural problems are difficult to solve when considering all angles; to the point you no longer want to automate.
I am referring to conundrums where risks are identified, which are specific to automation, yet also apply for the non-automated case. E.g. how to open a door when there is no power? How to pen the door when you have no key? Either case has a low probability. (at least in my case; have a 20kWh battery, and auto genset; 100% up time since 2013 when commissioned).
Have spares for critical components.
I have spare rPis and mirrored SSD, plus other things, such as Ethernet switches, micro-controllers (some critical one pre-configured to swap when lightning strikes)
I am really in agreement with @semperor. Being a developer myself, there is nothing more rewarding than using your own product days in and days out. Unlike a regular program / application that is used in specific context, the home automation system is always there and being used.
Here’s what I do related to some of the insights @Max_G made:
Create an account and push all your stuff (except for sensitive things such as passwords, address, and so on) into GitHub.
Document things that you did over time in Google Doc. I have one each for OpenHab, Raspberry Pi, Micro-controllers and Linux.
Add a monthly recursive Google Calendar to back up the PI. Obviously you should back up before and after some significant changes. But having a monthly reminder forces you to think if a further back up is necessary.
@Seaside: related to the testing of the system. Another approach is to create your home automation as a software application / system that has unit / regression tests with proper mocking. This means you can test the code independent of the hardware. Unfortunately, it requires a software engineering background.
) is to find someway to connect whatever devices you have to MQTT (e.g. using tasmota etc), then to HAB, then go from there. Is that right? Of course, that doesn’t work so well for devices that use significant processing in the cloud e.g. voice recognition, image processing.
).