Wow!!!
(Don’t show my wife, I don’t think her eyes can roll back any further)
With a DMX to Servo controller, that would be so easy to make with SPi LEDs and the DMX binding 
1 Like
Today i finished up my input rack for openhab ( i prefer hard wired door/motion sensors where possible) i bought a few omron plc input modules and a corresponding backplane and reverse engineered the pins of the backplane to allow me to pull in channel status into a arduino nano which uses serial link to python, then python to mqtt ( might try and use serial binding at some point)
3 Likes
Here’s another hour or so of my time, trying to get my head around the rules a bit more.
Sadly I don’t think I’m going to be winning an awards any time soon.
I once ‘Won’ the award of “Most Improved Dancer” at a training session, but I suspect that was because I started from a VERY VERY VERY low point.
Anyway, the mission today was to harvest the core facts from a BBC Weather RSS feed and turn it into something short that can scroll across a Velbus Glass Panel.
I’ve put the rule and other useful information here :- BBC weather RSS Latest Title split to <64 characters for Velbus OLED
FYI
If you want to learn about how to split strings and use the different parts, please do read all of the posted topic, @rlkoshak takes great care and goes into the fine detail of how splitting strings works.
I really feel I’ve learnt a lot from this experience.
nice, what are you flashing the with for use with openhab
I flashed them with Tasmota firmware so I can control them via MQTT / openHAB.
Not today, but this week.
Pushover recently added support for animated GIFs, so I altered my front door notifications to include short clips.
Converted GIF sample:
notification sample (animated on phone):
While I was at it, I created a custom landing page to get a live view and control the front door lock:
Cross-posting writeup from here: Blue Iris integration- HTTP binding, REST api
5 Likes
In the theme of cameras, I flashed hacked firmware on Xiaomi Dafang to replace my raspbery wifi cam based on motioneyeos (xiaomi is cheaper and seems easier to use, also prettier and have a better IR capabilities plus option to remove IR filter on demand. And of course the best thing for automation, it has MQTT status and commands.
So while testing it as a replacement I made a slow cooker observatory, so that I can turn off the slow cooker if meet looks done, while we are on the move. Took 5min to set all up, and 15min to take photo and write this down 
5 Likes
And the results of automation. Salt, pepper, not a single drop of water and after 3.5h on high (+1h cooldown) you get the tender and delicious beef cooked in its own juices.
And best of all, it is all automated, one timer rule and no interaction needed.
15 Likes
Hi,
maybe this is a binding for you instead of using the serial binding: https://github.com/openhab/openhab1-addons/wiki/SimpleBinary-Binding. Every item is supported and you do not need any conversion rule or
REGEX expression. It works quite well on openHAB2 too!
1 Like
No pics, because its “just code”, but i have started switching over to jsr223 rules and moved some of my multimedia and light scenes over to javascript files.
The learning curve is a bit flat, but the rules seem to run already smoother, even if i have to save them several times while improving them.
So my first impressions are, that it will be worth the effort and that it isn’t that complicated after you have made the first progress. 
6 Likes
And it will put you in a better position for future versions of OH. I need to do the same but haven’t had a chance to take the plunge yet. Are you using Lewie’s library? What made you decide to use JavaScript?
I bet a quick lessons learned/this is my experience moving over post would be very much appreciated, if not a full tutorial. 
How so?
Live got something in mind already and hopefully have some spare time for this.
Javascript:
I am digging into vue currently, i am doing web development with php and js for private usage for a longer time.
I love brackets^^
I am using an adpted version of lewies library currently.
I have added the timer and trigger part and removed all stuff that is erroring currently.
The smooth is aiming especially for the startup part of openHAB and while developing.
When i am changing rules dsl files they mostly have some delay after saving them.
Also there is a bug that fires the startup rules every time a rules file changes, which also causes some laod and delay.
With the js rules i can adapt the rule, save it and it gets refreshed immediately.
So smooth for me, means the progress/process during development.
1 Like
Exactly what I was looking for 
Indeed, I keep the files small and keep the start-up rules in mytask.startup.rules file while the code sits in the mytask.rules file.
Depending on the contents of the file and how many of the “primative issue” exists in the file, some rules are near instant and some take an while to kick in.
I’ll take the plunge and start new features in new rules.
1 Like
What did I automate / build today? Nothing with pictures but added functionality;
Came home a few days ago to find out SWAMBO had left and left the iron on. It was there, ticking away on the board. With dogs in the house this could have lead to a disaster.
Seeing as I have full scene control based on presence and time of day (Day-Home, Day-Away, Night-Home, Night-Away) and I also monitor and log many of the electrical circuits in the house I thought I could protect against this.
To do this with ML would be cooler but…
When a scene changes to one of the away scenes OH starts a timer, waits for 5 minutes and gets the average power consumed for the last 5 minutes.
This is then compared to the last 7-day average for the same scene…
If the 5-minute average is more than 10% higher than the 7-day average then it sends me an alert (email).
I’m still testing the numbers to see for false alarms etc but the grounding is good.
Once the framework is working I could conceivably even shut down circuits to try and protect things.
While I enjoy the flexibility this gives me I am wanting to move away from rigid rules like this and more into using ML to do anomoly detection with various feeds. But that’s a way aways yet 
2 Likes
This is fascinating.
I’d love to understand how you do this, but as my mind is happier with wires and cables, I fear it’s way beyond my abilities, but fascinating none the less.
Good luck
I’ll post the code bits up at some point. Actually very straight forward. The “wires and cables” are the fun part. I’m wanting to put CTs on to each circuit to monitor everything
Now that’s something I do know about
This Velbus input device can support 4 x 20ma CT coils.
https://www.velbus.eu/images/products/0/vmb4an.jpg
I’ve currently got it on test with these coils, and a few other sensors.
http://www.ebay.co.uk/ulk/itm/332675409469
This Velbus module isn’t currently supported in the publicly available openHAB2 binding, but there is a development version that does 
This is a xiaofang camera not Dafang, am I right? Which hack did you used which has MQTT support?
That really isn’t a bug, but expected behavior. At least that is how it has worked since OH 1.6 IIRC and in certain use cases it is a required feature. For example, let’s say a user has set up a bunch of ArrayLists and HashMaps that need to get initialized with information that isn’t known until OH is running (i.e. you can’t hard code in the values). You need the System started Rule to run when the .rules file is loaded so the global vars can be populated. Otherwise those values will remain uninitialized because your global variables get wiped out when the .rules file reloads.
NOTE: I strongly recommend writing Rules in this way. It’s a code smell and probably not the best way to achieve what you are after. But just because I think it’s a bad idea, I would not go so far as saying that this use case should not be supported.