I've just completed my setup (after exactly 3 years from moving in, priorities!) and even if I wrote all the code in C#, I could port it easily to LUA (I guess )

I've used Fully Kiosk Browser + 3D Printed Mount (check https://makesbymike.com/) and a custom HTML dashboard, all running on an Amazon Fire Tablet:

WAF is very high

Sorry for the Italian interface. First row is temperature/humidity sensors (esterno = outside, piscina = pool, salotto = open space, zona giorno = 1st floor, zona notte = 2nd floor, lavanderia = laundry room).
Then I have a bunch of commands/scenes sent to Vera to change blinds/roller shutters (they are automatically managed, but wife pretends to be smarter than code, from time to time ). Last row has notifications for washer/dryer, with the cycle end date. When doing its cycle, the background becomes orange, then green when completed. It's probably the best feature, since the laundry room is in the basement. There's also a link to cams (videosorveglianza) and I automatically open TinyCamPro in case of movement outside/doors/gates are opened.

Is there any interest in a generic wall mount tablet plug-in, offering simple dashboard (maybe json-driven) and integration with Fully Kiosk API?

I'm currently dimming screen on/off, get the battery status and schedule a 20-80 cycle for the battery, via a smart plug and a bunch of lua code. I planned for this when I did the electrical setup, so the tablet has a standard european 503 (recessed) box with ethernet, that I attached to the 5V into the network closet to feed the tablet. I'm updating the screen via AJAX every 30 secs.

Here's a behind the scenes photo as well

Since today is my birthday - and I still pretend to be unconventional - I'm giving away a present to this wonderful community and I'm releasing my first OpenSprinkler controller for MSR. It was real fun to code it - and while it's still WIP, it seems to work OK for me. It's polling-based at the moment, but I'll add support for updates via MQTT very soon (it's already partially coded).

Get it at (install is similar to MQTTController and such):

GitHub - dbochicchio/reactor-opensprinkler: OpenSprinkler controller for Reactor - Multi-Hub Automation

OpenSprinkler controller for Reactor - Multi-Hub Automation - dbochicchio/reactor-opensprinkler

Feel free to try it. It's beta software, but it's stable. I'll update it weekly until all the tasks from my todo list are empty.

Since I've learnt a lot from this controller, I'll explore new controllers soon.

Just run everything under docker, including ha, and a single nuc is more than enough. USB are easily mapped via docker.

So, it was time for me to move from Vera to something modern. It served me well, but I have new devices I want to add and old that I want to fully use. I have 3 weeks off in August, so plenty of times to tweak things.

Long story short, I moved and turned off my two Veras (one prod, one dev).

Hardware:

• Zwave.me controller, updated to FW 5.39, SDK 6.28.1 (it is necessary, since my Veras have the latest FW available). I opted for a 500 controller because of all the drama with 700/800 and the need to stay on something stable.

I have 60 Zwave devices, so starting from scratch was a big no for me.
I started from this famous guide, after taking a backup from the Vera Prod to the Vera Dev:

GitHub - rafale77/Z-Way: Zway plugin for openLuup

Zway plugin for openLuup . Contribute to rafale77/Z-Way development by creating an account on GitHub.

But it was not working. So, the route I went is:

• Go the Vera UI and go under Settings/Z-wave settings, take a screenshot (HouseId in particular).
• take a backup from the prod system
• extract the file /etc/cmh/user_data.json.lzo from the backup
• move the file to the /tmp directory of your dev system
• execute pluto-lzo d /tmp/user_data.json.lzo /tmp/user_data.json
• open and edit the file, looking for a port node with something like /dev.. and put /dev/ttyACM0 inside. save the file.
• run pluto-lzo c /tmp/user_data.json /tmp/user_data.json.lzo
• copy the .lzo file to the backup, in the same position
• insert the Zwave key into the USB of your dev Vera
• reboot the dev Vera
• wait a lot for it to finish ️
• it will probably say that it cannot start ZWave, don't worry
• Go the Vera UI and go under Settings/Z-wave settings, you should see the old HouseId. Anyway, double check with the screenshot you took previously: if it matches, you've moved your Zwave Network to the new controller!

Shutdown the Veras, take the USB Key with your ZWave network and move it to ZwaveJS!
I've installed it via Docker, very easy. Go for ZwaveJS UI, so you got the UI as well.
Interview the nodes, have patience. Some battery nodes will need wake-ups, others will complete automatically. I had to re-pair a couple of devices because of incorrect pairing with Vera (security and non-security mixed together). In this case, pro tip: reset the device, and then use the replace function from ZWave JS, to have the same node id.

Now, if you're already running under Reactor, you'll need to rewrite all your logic. I asked ChatGPT to write me a Powershell script to get the device from the Veras and build the new naming convention. The logic is that AltId in Vera is in fact the ZWave Node ID, and on Reactor you'll get device like zwavejs>nodeid-endpoint (ie: 95-0, 95-1, etc). So, I built a script that replaced all the occurrences from the storage of Reactor (did I mentioned to do a lot of backups?) and set the name via ZwaveJS MQTT apis. Then, I build an Excel file (thanks ChatGPT!) and renamed all the endpoints in Reactor (manually, no APIs to do so). It took me about an hour.

Now, no more trip/untrip lost along the radios, and a blazing fast ZWave network to enjoy.

Since a couple of devices are recognized in a different way, I had to re-write a couple of rules (and wait a couple of fix here and there by @toggledbits for devices not properly recognized, thanks!), but I was OK in a couple of days, and ready to run by the first afternoon, so I maintained an high WAF.

Now, I could experiment the joy of SmartStart and proprietary commands.

Thanks to the people that moved before me, inspired me and to @toggledbits for the incredible platform that has built in the latest years! Feel free to ask question if you need help.

As another one asked for it on the other forum, I finally created a new plug-in for Telegram notifications: https://github.com/dbochicchio/vera-Telegram/

You can:

• send text messages
• send (still) images
• send videos (gif or mp4)
• send silent notifications

I remember @CatmanV2 was searching for something similar (maybe?).

I'm using it to send push notifications to me and my wife, using a group. I have my own code streaming my cameras and sending a video as gif based on certain events (ie motion sensors or door/entryways left open). While this part is not included into the plug-in, if you're able to get a video yourself (by pointing to a URL), you'd good to go. Still images from cams (or, let's say, your favorite weather map, or any video/gif/image on the Interner ot local) are supported as well.

100% compatible with bot Vera and openLuup (where it was developed, anyway).

Feel free to ask questions or suggest new features.

I started with Vera Edge, then Plus, and eventually moved my Z-Wave network to Z-Wave.me UZB. Recently, I wanted to experiment with Z-Wave Long Range, so I needed a new controller. I had Home Assistant Connect ZWA-2 on my radar for a while, and I pulled the trigger thanks to Black Friday offers. It was the least complicated migration ever: back up the old, unplug it, stop ZWaveJS, plug in the new controller, and restore the backup—done in a breeze.

I let the mesh adapt for a couple of days, and the result is impressive: 80% of my devices are now reporting directly to the controller. The Z-Wave network feels crazy fast. My setup includes about 70 devices, and I struggled a lot with Vera. I had missing reports on UZB as well, even if sporadic. In the first days of use, this new setup seems definitely better, and its range is phenomenal. More on that later.

Since I was at it, I moved my ZigBee network from Hue Bridge (only lights) to Home Assistant Connect ZBT-2 and ZigBee2MQTT, because I wanted to add more ZigBee devices to my network. It seems that all the little weird devices are ZigBee now—I bought a couple of temp/humidity sensors and a ThirdReality Night Light. I'm using it to turn red if the alarm is armed, and as a white night light in the hallway when not armed: very nice to automate with Reactor via Home Assistant.

The ZigBee mesh is still small at 10 devices, but it will eventually improve.

Here's a pic of the two antennas: ZWA-2 on the left, ZBT-2 in the center, and a 33cl bottle of water on the right for comparison.

The ZWA-2 is huge. No wonder it's able to span across three floors and reach the garden with no hops. Mind you, my house is concrete and glass, so not the best in terms of signal. Highly recommended if you want a very powerful Z-Wave antenna, with support for Long Range as well.

I've moved all the triggers and rules to MSR now, and I'm pushing everything to my MQTT broker for further integration, but some code is still on my Vera because it's easier at the moment. I've moved back a lot of code to my C# based tool, because it's easier for me.

After a full week of use, I've got a couple of desiderata to further improve this wonderful tool:

• I would like to see the logs in the web UI. I'm frequently tweaking things and opening an SSH connection just to see the latest logs is overkill. Maybe something to see the streaming logs will be perfect, but refreshing them is OK
• More info about reactions latest execution - or the ability to see them via MQTT. Ideally, show me the latest 4-5 executions
• start page directly to status, instead of about, after the first time I've seen the license
• the ability search for device ID/alias in the Entity Action's Chose Entity window - I've spent years in my Vera and I know the IDs instead of the name - sad but true story
• a way to see controllers' status and their health in the UI - and maybe start/stop them individually, because I'm seeing there's a start and a stop action in the controller base class
• the ability to use an MQTT message as a trigger/condition - I'm effectively using the MQTT bus as a communication bus, so all my things (including Vera) are sending MQTT messages for various things, like notifications, TTS, cams, etc - this is handy because I can add independent reactions to statuses in different part of my system/using different tools
• support for re-ordering in mobile browser (iOS, for me)
• a tool to see where I'm using an entity, as trigger or condition

Keep them as suggestion, no pressure. Thanks for the hard work @toggledbits !

I've moved many of my MQTT devices to Reactor, so I've coded a couple of templates and I'm publishing them for anyone in the same boat:

GitHub - dbochicchio/reactor-mqtt-contrib: Contrib MQTT templates for Reactor

Contrib MQTT templates for Reactor. Contribute to dbochicchio/reactor-mqtt-contrib development by creating an account on GitHub.

I'll add more in the future, since I still have a couple of things running in my own bridge that I'll eventually move to Reactor with dedicated templates.

Let me know if you need other templates, I'll probably add a couple more for Shellies (button as scene controller and i3/i4 as scene controller).

Here's my second attempt at a Reactor Controller, this time to integrate LG TVs:

GitHub - dbochicchio/reactor-lgtv: Reactor controller for LG TV (webos)

Reactor controller for LG TV (webos). Contribute to dbochicchio/reactor-lgtv development by creating an account on GitHub.

Standard capabilities are provided and TV volume, mute and switch status are controllable.
There's also an action to send toast notifications on your TV.

webos 5+ is required.

I think lua drivers for devices is a win-win situation, applied to a store to easily distribute them. And local APIs are coming too. It seems they’re doing the opposite of eZlo here…

I'm still using my VeraPlus for Zwave, because migrating Zwave is boring and I still have more exciting things to do (and it never worked so beautifully as with only Zwave duties via MSR), but I'm not surprised at all, because from my experience (I stopped testing one year ago) this new controller is DOA. Too little, too late, and a wonderful community thrown under the bus with nothing in exchange.

Since I know there are fans of Shelly's products (hi @akbooer), I'll post it here too:

Shelly Europe

Shelly provides advanced smart home automation solutions for seamless control of lighting, temperature, and energy. Make your home smarter today.

Up to 45% discount, and 2/4 packs discounted as well.

Well, I think it has a meaning when we add dashboards to the mix. I’ll vote for it, plus combo device (like HA) to express complex devices. I’m using this approach right now in my own dashboard system.

I just released v2 of my Virtual HTTP Devices Plug-in. As always, 100% local, 100% standard, mobile friendly and working on openluup/altui as well.
GitHub

vera/VirtualDevices at master · dbochicchio/vera

LUA Scripts for the eZlo Vera Platform (UI7). Contribute to dbochicchio/vera development by creating an account on GitHub.

What’s new in v2:

• Master/Children: now you can just create a master and have any number of children attached. They will still work separately, but this will greatly improve memory consumption on Vera. Please see GitHub for guidance on migration. No need to do it unless you have many devices on your system.
• async update of device's status. If you want to update the status of your device separately, just return something different than the HTTP code 200/300 family. it’s useful if your device doesn’t complete the response with the call and you want to update its status. Just use a normal Vera call to update the corresponding variable
  -added support for Scene Controllers (see my post in Shelly i3 for a use case)
• more work around switches/heaters
• stabilization and fixes

Get it from GitHub or from AltAppStore.

@librasun thanks, but I have a job (well, I’m joking with my colleagues that I’m probably doing 6-7 jobs at once) and I’m doing this for the pleasure to give back and find new friends (and because I used to travel a lot and this year I had a lot of free time). So, as I’ve already said to others (@Pabla is here too) I’d appreciate if you could donate to groups trying to create a more inclusive environment, ie promoting a dev career for girls or minorities. Thanks

So, I was messing with my Alexa routines and ha bridge, and I want to share something very cool you could do with the ability to get the last Alexa that heard your command. I mentioned it a couple of times on the old place, but Vera's OS is missing the jq package, but openLuup could have it installed.

Basically, just execute -lastalexa with my VeraAlexa plug-in:

local lastAlexa = luup.call_action("urn:bochicchio-com:serviceId:VeraAlexa1", 
  "RunCommand",
  {Command="-lastalexa"}, 666)

Then use it in your scene, to dynamically generate your TTS response with the device you've asked your question seconds before!

local temperature = 25 -- get it from your sensor
luup.call_action("urn:bochicchio-com:serviceId:VeraAlexa1", 
  "Say",
  {Text="Ok, outise temperature is " .. temperature .. " degree", Volume=50, GroupZones= lastAlexa, Repeat = 2}, 666

Very cool indeed

Caveat: I'm still bored, so I'm building a lot of things lately (I used to travel a lot, so the last year has been really different - but I digress).

Last week I built two car sensors using a Shelly Button1 in each. It's a new device, with a battery and USB charging (see https://shelly.cloud/products/shelly-button-1-smart-home-automation-device/)

I've placed one in each car under the leg rest. I'm parking outside (my house is modern architecture, I have a covered terrace that's my open space, so cars are outside the garage, but covered), but WiFi is still reachable.

When plugged via USB, the device is sending a new MQTT message upon boot, and that's great for leaving home. It usually takes less than 10 seconds from when I open the car. This action will open my car gate unless party mode is on or the gate is already opened. It will automatically close it after 40 secs.

When coming back, it will reconnect in seconds (less than 10) and send a new online MQTT message. The trick here is to get the uptime via an HTTP call to /status (I've asked them to add to the MQTT message) and if more than 10 seconds are passed from the last boot, I'm assuming the car is coming back and the gate needs to be opened, and then closed automatically after 40 secs (again, if no party mode is enabled and if the gate is closed upon arrival).

It's a very simple thing to do, but I'm loving it. Obiously, my wife was like "you're really lazy", but I know she will love this eventually. Saving me from 10 clicks to a remote is what home automation really is

No JavaScript needed. Let me take some time later today to prepare something when I’m back home. I did something similar for water valves.

@librasun The plug-in will take care of it. So, just set configured to 0 and it will install it.

I've had a very busy week, but tomorrow I'll have more time to re-try from scratch. Keep in mind that this is using some internal amazon stuff and the chances that they changed something is high. Anyway, it should not create <s>... unless you have announcements enabled. I'll take a deeper look tomorrow. I've tested with 7.32 beta, but not this build, and it worked, but I've not tested all the possibile variants.

We're working on a (giant) new door for our house, and I'm exploring HomeKey locks, because I have CarKey on my cars and I love it - but unfortunately, due to Apple and their demands to have the lock and the reader all in a single hardware piece, door locks in Europe with HomeKey are few - and the few available are after market solutions, so not aesthetically WAF-approved. And then, I wondered, how cool could it be to open the garage door with the same HomeKey?

So I went down thru a rabbit hole and then found this:

GitHub - rednblkx/HomeKey-ESP32: ESP32 HomeKit Lock with support for Apple Home Key (reverse-engineered)

ESP32 HomeKit Lock with support for Apple Home Key (reverse-engineered) - rednblkx/HomeKey-ESP32

I ordered a couple of things, and started tinkering. After a couple of hours, I had it implemented under Reactor via MQTT and on my desk, turning ON a light when the key is recognized. It costed about 20 bucks per entry, so not bad at all.

We only have iPhones at home, because of CarKeys and CarPlay - but we're not really using Home, so I had to buy an HomeHub in order to share the key - I got an Apple TV 4k that's basically just doing the HomeHub part. I'll eventually expose other things to Siri via Homebridge or HomeAssistant - or maybe not. HomeKey is the feature, for me.

Using Express mode, you just pass your watch/device on the reader and the key is recognized. You get the same key, but different device ID for a different watch/phone.

The logic is MQTT-based, so every time you pass a tag (MiFare is supported, but it's less secure because easily duplicable), you get a message at a given endpoint. You grab the keys via your virtual device, and check if they're valid in your own logic. I have a tag capability mapped to represent the key id, the device id, and a very easy logic to determine if the data is valid and the entry should be open. Remember, Key ID will be the same, Device ID will be unique across your devices (watches, phones) per person (the key is easily shareable in your family). See this screenshot:

You need to map the virtual lock in Reactor to the real status of the entry it's representing - but that's done using the lock capability of the device mapped via MQTT. See my template for it https://github.com/dbochicchio/reactor-mqtt-contrib
Setup is very easy.

Since the reader itself isn't doing anything special, it's the same security as a ZWave door lock: if they open the case, no contacts is exposed, since this is just a reader, where the security is inside your phone/watch. You have -of course - to use it to drive your real lock. Easy job for the garage, doable for the new proprietary lock for the door, with 12v input to unlock - via ZWave or whatever - and auto-lock feature.

A couple of photos of the various steps - and the final case I found for 5 bucks on Ali, to mount it securely outside (it had the original electronics and I took it apart to insert mine - I recommend a smaller ESP32 if you have better soldering skills than mine).

I'll mount it with the Garage Door outside - very handy during pool season, since this is the easiest way to the bathroom after some time chilling. It's powered by a 3,3 converter housed inside the house, eliminating the need for the bulky USB connector. The reader is completely covered, so the fact that is not really IP-6x is not a problem: it will not get splashes at all.

Feel free to ask me anything, if you want to embark into a new adventure.