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'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.

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

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

Since I know there are fans of Shelly's products (hi @akbooer), I'll post it here too:
https://shop.shelly.cloud/

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

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.

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

Ok, I've just prototyped a way to send a message on actions and I'm happy to report it's done

You can mix and match different kind of commands (lua, mqtt, http, curl, etc).

I'll try to do some refactoring in order to use a common lib for all this virtual devices, then backport this to all of them, then start adding watches, so we could subscribe to mqtt messages and update variables. @PerH @akbooer

@toggledbits I found that AltHue by @amg0 is still using IP attr. I'll probably send him a pull request, since it's very popular.