The Time has come

There are two different apps for this. The native Hubitat app only allows one-way sync (can't remember which direction). Other Hub community app does a 2-way sync between a physical device on HE and a virtual device on ST.

I used Other Hub as a migration tool. Reset device (which leaves it listed in ST but non-functional of course), pair to Hubitat. Add to Other Hub app, which replicates a virtual device back to ST. Replace non-functional physical device in ST automations with new virtual device. This allows your automation to continue to run on ST while you migrate devices over to HE. If you do this one at a time or in small groups you can minimize down time and let everything continue to run during the transition.

I migrated all my devices first and left automations running on ST, then once device migration was complete, started rebuilding automations on HE. Having both hubs running together allows a smooth transition rather than just pulling the plug and starting over. If you were wanting to start from scratch though, you probably won't have much use for this.

So I thought the same way you did originally but found that linking them made moving things over and testing much easier and less likely to cause disruption. You likely won't have to run it that way for very long..
:grin:

(replied to myself for some reason!)

1 Like

I didn't bother linking. I just moved everything in one chunk. Took a number of hours, but was better to me than messing around. I think I'm a "pull the bandage off quickly" kind of guy, though.

1 Like

I have had good success with channel 15. This would also put a good gap between your ST hub and HE.

Also the Iris Smart Plugs make good Zigbee repeaters.

The Goal is to disconnect ST. I have no intsrest in managing two systems in parallel.
As such I don't see the relevance on such tool. What I'm missing?

To elaborate - Starting with a new/unknown platform made me a tad nervous about preserving functionality. I was able to move a device or groups of devices over and still have it function under ST until such time as I created a rule for it in HE. Was then able to take my time and switch things over as needed. I had 80+ (over 100 now) devices and a complete switch might have been more of a pain or so I thought. In hindsight for my use-case it was an unfounded worry - things just worked. I probably could have just moved everything over like @JasonJoelOld.

Continuous integration using the hub link app might be easier than doing parallel testing especially if you need to revert back.

There has been some discussion about the Iris stuff - I have 2 plugs and ended up disabling the Zigbee repeating part.

This was an issue with Z-wave not ZIgbee repeating. It also had to do mostly with Iris plugs that had old firmware. There was firmware update that resolved the Z-wave issues. I have no issues with the Zigbee repeating with multiple plugs. I do not use the Z-Wave repeating because I have a ton of Leviton dimmers which provide a good mesh already.

1 Like

Ah, yes you are correct! I have plugs that have not been updated and it was indeed the Z-wave repeating bit...:grinning:

Ok it has arrived.

I have plugged it in and spent just literally 5 minutes with it. Have done several backups on critical milestones.

  • Booted, Registered, configured location, modes, zigbee Channel (used 22).
  • Installex all the Native apps i wanted to use for now: Mode manager, HSM, Simple Lightning, Dashboards, Chromecast (first hiccup).
  • installed Philips Hue Bridge Integration.

What I have found so far easy process overall.

Was not able to detect my Chromecast devices, but I know what's the issue. I have 2 IP ranges within the same network. 10.0.0x that manages all my intranet devices connected into the Mesh Wifi this mesh wifi connects to an ISP router and 192.168.1.x (the ISP router) for those not directly connected to the mesh Router. This are basically the ST Hub, Hubitat, the Mesh Router and Philips HUE. Every single device in this ranges can communicate on every single protocol with each other.
The issue here seems that the Native app is not sending a global broadcast to the network but just to a subset of it. Any clues how I can solve this? For example all my cast devices have fix IP. Can I force a discovery on those IPS?

Philips Hue integration was flawless. All devices & Groups migrated.

So far I have near instantaneous responses from the lights.

Will continue later on.

Edit: logs from Chromecast discovery:

app:12019-01-10 21:30:27.635 infodiscovery stopped...

app:12019-01-10 21:30:15.399 infodiscovery started

2 Likes

I had to add several zigbee repeaters to get my zigbee mesh to stabilize when I previously didn’t notice issues while using ST.

And I live in an apartment, it’s not very big. There are a ton of WiFi networks all around me though.

Point is, the Hubitat zigbee radio may not be as strong as ST’s. I do think I read that one of the HE firmware updates boosted the zigbee radio transmission power or something.

Ok I end up adding a new sattelite into the orbit system. Now I have too much cover and I believe I will upset my neighborhood WiFi networks (I live in a building with 42 apartments).

One odd thing I noticed was that the HE hub was not updating the IP settings. I was ensuring to shutdown the hub. Only after I shutdown and. Waited for 15m he got the new IP.

Anyway I added the MaC Address to the reservation list.

  • Lights all transferred ok (Through Hue)
  • Google Assistant Disconnected from ST and connected to HE. Clunky but worked ok.
  • All custom drivers needed loaded.
  • Netatmo App and Drivers loaded and seem reporting. Missing the sound attributes for the Dashboard and Rule machine. @bravenel would be possible to add this? I have a few rules in Webcore where I'm notified if sound goes above a certain level after a certain time. In fact this is the main reason why I went with Netatmo (very few sound sensors in the market). To avoid neighbors complaining sound is too loud :slight_smile:
  • Chromecast now working as intended.
  • Only wierd thing is how pages behave I need to click a few times on white space for the button done to move away from greyed out and allow to be clicked.

Tomorrow is Xiaomi pairing day.

1 Like

Well.... The bug was in me and I moved 70% of the sensor/lights.

So far all good.
Had a few issues pairing the devices bit all sorted (info on the Topic Xiaomi Question).

Found a lot of attributes I used in ST that are not available neither for the Dashboard or in RM. Does anybody knows if we can add them or if it is only support? I need a few Netatmo variables and a few for Xiaomi added.

1 Like

You should list a few examples of missing variables, that might help someone comment more specifically. I don't have Netatmo or Xiaomi, so can't help with this one, though.

For Netatmo Base Station:

Current States

  • carbonDioxide : 771
  • humidity : 51
  • lastupdate : 01:40
  • max_temp : 15.9
  • min_temp : 15.6
  • pressure : 1035.8
  • pressure_trend : up
  • sound : detected
  • soundPressureLevel : 36
  • temp_trend : stable
  • temperature : 15.6

For Netatmo Outdoor

  • battery : 90
  • humidity : 57
  • lastupdate : 01:40
  • max_temp : 9.3
  • min_temp : 8.6
  • temp_trend : stable
  • temperature : 8.6

Than there are two additional modules I don't have for Rain and Wind so can't test them.
The attributes from the drivers are:
attribute "WindStrength",
attribute "WindAngle",
attribute "GustStrength",
attribute "GustAngle",
attribute "max_wind_str",
attribute "units",
attribute "lastupdate",
attribute "date_max_wind_str",

And
attribute "rain",
attribute "rainSumHour",
attribute "rainSumDay",
attribute "units",
attribute "lastupdate"

For the Xiaomi Vibration Sensor not sure how to integrate this one to be honest.
The Sensor detects Tilt/Drop/Stationery/Tap/Knock/Vibration

Current States

  • acceleration : inactive
  • activityLevel : 162
  • angleX : 1.3
  • angleY : -1.2
  • angleZ : 88.2
  • battery : 100
  • lastCheckin : 1547259030750
  • lastCheckinTime : Jan 12, 2019 2:10:30 AM
  • lastDrop : 1547252578339
  • lastDropTime : Jan 12, 2019 12:22:58 AM
  • lastStationary : 1547252728619
  • lastStationaryTime : Jan 12, 2019 12:25:28 AM
  • lastTilt : 1547252460521
  • lastTiltTime : Jan 12, 2019 12:21:00 AM
  • lastVibration : 1547252663572
  • lastVibrationTime : Jan 12, 2019 12:24:23 AM
  • motion : inactive
  • numberOfButtons : 1
  • sensitivityLevel : Low
  • sensorStatus : Stationary
  • threeAxis : [1.3, -1.2, 88.2]

In the Hubitat Dashboard, you can simply use the Attribute Tile, which allows you to type in the exact, case-sensitive, name of the custom attribute you want displayed from a device.

1 Like

You might seriously consider removing the sendEvents and custom attributes associated with these events, they aren't used by any apps, and aren't doing your database any good.

How would I do that? Where should I start? Not being a coder this is a little of alien language to me.....
Would it be just a case of removing them from the device code?

I would contact the author...

1 Like