Seeking Advice:

[CatmanV2]

So what are my next steps, gents?

I assume a UZB stick will need to be purchased and I can look at migrating some of the devices that are easy / non critical over.

Or perhaps a better direction would be to go for the HA Bridge plug in and then get Alexa skill working?

Thoughts?

C

[CatmanV2]

Dived in to get HA-bridge up and running. Not too hard, but getting the config was a bit trickier. Using the base instructions here:

GitHub - bwssytems/ha-bridge: Home automation bridge that emulates a Philips Hue light system and can control other systems such as a Vera, Harmony Hub, Nest, MiLight bulbs or any other system that...

Home automation bridge that emulates a Philips Hue light system and can control other systems such as a Vera, Harmony Hub, Nest, MiLight bulbs or any other system that has an http/https/tcp/udp int...

I installed in my home directory on Debian so

mdkir /home/catman/ha-bridge
cd /home/catman/ha-bridge
wget https://github.com/bwssytems/ha-bridge/releases/download/v5.3.0/ha-bridge-5.3.0.jar

Creating the service file gave me a choice, I could either change the file or make symlink the folder referenced, which was what I actually went for

sudo mkdir /home/pi
chmod 555 /home/pi
cd /home/pi
sudo ln -s /home/catman/ha-bridge/ ha-bridge

The systemctl was all fine but it failed on start with the pretty obvious fact that java was missing!

sudo apt-get install default-jdk

Then it fired up fine, but going to my IP address gave me the Debian apache2 landing page. So that needed fixing. I decided to change the port number to 8080 using:
-Dserver.port=<port number>

So my service command is now:

ExecStart=/usr/bin/java -jar -Dserver.port=8080 -Dconfig.file=/home/pi/ha-bridge/data/habridge.config /home/pi/ha-bridge/ha-bridge-5.3.0.jar

Quick demon reload and ha-bridge reload and there it is on port 8080;

Excellent!

C

[CatmanV2]

Even better. Using HTTP to my vera IP I have successful voice control!

C

[CatmanV2]

This post is deleted!

[rafale77]

They are at the right place. It's gotta be something else. Unless the device json file indicates a completely different path... Or altui can't read the json files?

[CatmanV2]

@rafale77 said in My migration from Vera, or what I did on my holidays:

They are at the right place. It's gotta be something else. Unless the device json file indicates a completely different path... Or altui can't read the json files?

I don't know what it was. It all started working when I checked in another browser on another machine.

FWIW some of the ones originally in 'icons' had had 0b file size. I supect there was an abortive copy at some point and then subsequent 'get Vera files' took a safe option. I manually scped them all over, but still didn't work when I posted that message.

I guess some odd caching (even though I was very rigorous with my cmd-R

So another challenge has reared its head.

Tried to start migrating some of my Reactor sensors over per my other thread.

Turns out that Vera Bridge seems to poll Vera every 80 seconds or so. That causes reactor to see an update sl_Central_Scene change and thus triggers. This took some time to work out!

This puts something of a crimp in my plans. My understanding is this:
I can plug my (soon to arrive) UZB into my Vera and move all my devices on to it. Then plug it into the NUC and there they all all. That was the big bang I was rather hoping to avoid.

What I suspect I can't do is plug the UZB into the NUC. Un pair the controllers from Vera, pair them to the NUC, confirm a stack of functionality and then plug the UZB into Vera.

Or am I being too pessimistic?

Dunno if this post needs to be moved?

Cheers

C

[rafale77]

@CatmanV2 said in My migration from Vera, or what I did on my holidays:

I don't know what it was. It all started working when I checked in another browser on another machine.

FWIW some of the ones originally in 'icons' had had 0b file size. I supect there was an abortive copy at some point and then subsequent 'get Vera files' took a safe option. I manually scped them all over, but still didn't work when I posted that message.

I guess some odd caching (even though I was very rigorous with my cmd-R

Not uncommon then. Glad you got over this. The icons do get aggressively cached by browsers and sometimes require some brute force "empty the browser cache"

So another challenge has reared its head.

Tried to start migrating some of my Reactor sensors over per my other thread.

Turns out that Vera Bridge seems to poll Vera every 80 seconds or so. That causes reactor to see an update sl_Central_Scene change and thus triggers. This took some time to work out!

Hmm I don't remember it doing this. A number of people are running reactor through openLuup verabridge I believe and I have never heard of it. I don't use reactor myself though.

This puts something of a crimp in my plans. My understanding is this:
I can plug my (soon to arrive) UZB into my Vera and move all my devices on to it. Then plug it into the NUC and there they all all. That was the big bang I was rather hoping to avoid.

This is my recommended migration method indeed.

What I suspect I can't do is plug the UZB into the NUC. Un pair the controllers from Vera, pair them to the NUC, confirm a stack of functionality and then plug the UZB into Vera.

Not fully understanding this sentence. Unpair what controllers from vera?

[CatmanV2]

Apologies. The devices in question are Remotec ZRC-90 keypads and Zwave.me keyfobs.

I have used these for many years to trigger activities in Reactor (although frankly with Alexa and the new less cloud based, they get very little use)

Each of these has an sl_scene attribute and an sl_scene update attribute. Because sl_scene might not change from one execution to another, you need to use both.

The issue I hit is that every 80 seconds or so the Reactor sensor would trigger. Looking in Openluup's logs:

2020-06-22 14:17:48.358   luup.variable_set:: 10238.urn:micasaverde-com:serviceId:SceneController1.sl_SceneActivated was: 4 now: 4 #hooks:0
2020-06-22 14:19:29.972   luup.variable_set:: 10238.urn:micasaverde-com:serviceId:SceneController1.sl_SceneActivated was: 4 now: 4 #hooks:0
2020-06-22 14:21:11.559   luup.variable_set:: 10238.urn:micasaverde-com:serviceId:SceneController1.sl_SceneActivated was: 4 now: 4 #hooks:0
2020-06-22 14:22:53.595   luup.variable_set:: 10238.urn:micasaverde-com:serviceId:SceneController1.sl_SceneActivated was: 4 now: 4 #hooks:0
2020-06-22 14:24:35.115   luup.variable_set:: 10238.urn:micasaverde-com:serviceId:SceneController1.sl_SceneActivated was: 4 now: 4 #hooks:0
2020-06-22 14:26:16.532   luup.variable_set:: 10238.urn:micasaverde-com:serviceId:SceneController1.sl_SceneActivated was: 4 now: 4 #hooks:0

Which was causing the sensor to trip (actually as it should) even though there was no actual button press.

What I would like to do is un-pair these devices from Vera and pair them to my UZB stick while plugged into the NUC. Get those Reactor sensors migrated over properly, then take the UZB stick back to Vera and move the rest of my devices.

Does that help?

(NB given the progress I've just made it might all be a moot point anyway as my most complex and WAF testing piece of automation seems to have moved over without issue) Not sure how to test it though

Cheers

C

[rafale77]

I see. Yes of course you can do that. The migration from the vera is really meant to prevent any exclusion/inclusion which I know can be tedious depending on your device but if you want to exclude these devices from the vera first. Run the migration and reinclude them on z-way, it is up to you.

[CatmanV2]

@rafale77 thanks!

C

[CatmanV2]

So long day working round some gotchas.
What have we learned:
Scene controllers behave a little oddly under Verabridge it appears

Restoring Reactor sensors (one at a time)
First back up your Reactor from the Backup and Restore tab. Download it and then scp to you Openluup install directors
Install Reactor on your Openluup host
Create a new sensor
Move it to the right room
Restore the desired sensor onto the sensor you just created.
Go to to tools tab to fix it (assuming you have the correct version)
For testing I disable the Vera instance and enable the Openluup instance.

Once you're happy, you can delete the Vera instance.

Vera TTS was simplest of those so far. Install from Alt market place.
Copy your hosts, username and password into the Attributes. Then scp your .alexa.cookie from /storage/alexa on the Vera into /VeraAlexa on your Openluup device

I actually found it easier to copy the contents and create a new file than working out how to SCP hidden files, but Filezilla will do it simply

iPhone locator.
These don't come across well it seems. It's probably easier to create them from scratch.

C

[therealdb]

@CatmanV2 remember to install Jq and enable the flag. You'll get sync'ed announcements and much more!

[CatmanV2]

@therealdb thanks for the reminder. So that's done (well Use announcement set to 1)

I've configured all my Echos to have announcements enabled, but how do I actually send one? If I use Reactor>Device Action>Say> with group zone ALL they are still unsynced. If I use group zone Everywhere (the name of my group) I get no sound at all.

Cheers!

C

[therealdb]

Look at the logs. The group name is the way to go. ALL will still cycle.

[CatmanV2]

@therealdb said in My migration from Vera, or what I did on my holidays:

Look at the logs. The group name is the way to go. ALL will still cycle.

Logs don't log stupidity

Was firstly using the Vera instance, then trying to set announcements on the Vera instance. Setting it on the Openluup instance and using that worked first time

C

[akbooer]

@CatmanV2 said in My migration from Vera, or what I did on my holidays:

Logs don't log stupidity

...we could add it as a feature, but you’d have to sign up to be a beta tester.

[CatmanV2]

One thing I could test with aplomb

Cheers

C

[CatmanV2]

Amusingly and with full reference to this:

I've not had a Luup reload since Monday lunchtime. Odd since all my automation is still on the Vera. I have, however, killed all the Vera / Alex skill availability

C

[therealdb]

@CatmanV2 not suprising at all. If you remove all the load from the controller, it will be stable. If you don't have too many (let's say 60+) devices, Zwave will be stable enough. When you have a lot of devices and/or some not-really-supported-but-works-with-Vera (TM) devices, the Zwave network stability can dramatically decrease.

[CatmanV2]

But I haven't reduced the load, is my point. All my devices, all my automation apart from stuff that I use Alexa for, is still on the Plus. In fact, the load should be higher since it's getting polled by the Vera Bridge.....

The only real difference so far is that I use HA bridge running on the new Openluup box to do voice control. And that's hilarious. Even running through UI7 by doing a get to the Openluup box which which then goes through Verabridge, 90% of the time the switch has changed before Alexa has managed to say 'OK'

C