Looks like I've managed to find a hub in the UK, so I should be joining the ranks pretty soon.
One thing I've just twigged; on @dman2306's screenshot it shows "Iris V1 Zigbee" alongside "Zigbee", which I assume is Gen 2. Are Gen 1 and Gen 2 devices supported on the same Hub at the same time?
Zigbee refers to any ZHA application profile zigbee device, not just the Iris v2 and v3 devices. I think that ZLL application profile devices are supposed to fall back to ZHA when connected to a ZHA zigbee coordinator (like Hubitat), so I believe they are supported as well but don't quote me on that (tagging @SmartHomePrimer/@bertabcd1234/@ogiewon for the real answer).
I don't have any Iris v1 devices, but it is my understanding they can be used on the same Hubitat alongside ZHA profile devices.
That would be fantastic. The method on the Systronics RF system is to have two Zigbee networks, one for "Iris / AlertMe Gen 1" and one for "Modern ZigBee" with two separate Digi XSticks, but I have no knowledge of exactly why this is their preferred method.
I guess I shall discover for real in a day or two... 
One last point about Xiaomi devices:
Welcome to Hubitat!
We don't either, as once joined to the hub, iris v1 devices seem happy sharing the network with standard zigbee zha 1.2 devices.
The alertMe (iris v1) do have a very different join process, hence having their own dedicated ui command to initiate pairing.
I had this too, with Systronics RF. The Salus SP600 SmartPlug had come out very well in their range testing, so I used that and had no end of problems with the network completely falling apart randomly. Once the network was dead, nothing would recover it except for resetting each individual device with the system in pairing mode, which hooked everything back together.
I abandoned the SP600 plugs only fairly recently for the Hive 'Active Plug' SLP2b and these have been excellent with the Xiaomi gear. Previously, if anything fell off the network for any reason it would never reattach. With the SLP2b, on the rare occasions I've seen a light switch drop it always reattaches.
Shame, those SP600 plugs are physically a very nice size to work with.
This is great, really interested to see what I can get up and running. The AlertMe / Iris v1 kit has performed brilliantly for me since... wow, my signup email is dated 25th February 2009. 
We currently have drivers for 4 or 5 alertMe devices, however we don't expect further development of additional devices at this time.
So long as there are Smart Plugs, Motion Sensors, Buttons and Keyfobs I should be good to go. I understand it's possible for community drivers to be made? If so I don't mind looking in to that.
The more esoteric ones I have are the Power Clamp (incoming mains supply) and the Lamp, which is fun little RGB LED indicator light that would be nice to have back, but is no deal breaker.
These are the 6 built-in drivers for Iris V1 devices. Looks like you're all set.
Thanks, @aaiyar, appreciate it!
I see there's a community driver for the few Hive plugs I have and also for every Xiaomi device I own so I'm looking forward to the mail. 
Not seen any confirmation that the AlertMe SPG 100 (their original smart plug) is supported, but I find it highly unlikely that it wouldn't work, or at least be made to work with minimal effort.
These things have been bulletproof and they contain a battery backup, which keeps your mesh active even during a power outage (for security system use). I've not found another UK smart plug with that feature.
Hub arrived today! I've spent most of the evening messing around with it. I'm pretty adept at pairing the devices I have, given the beta testing I'd done for the Systronics RF system, but the Hubitat hub made it very easy indeed. In fact, I think every device I tried to pair worked within the first two attempts.
The most important ones to get working were the SPG100 UK smart plugs / outlets. They weren't recognised as Iris V1 Outlets automatically, so I had to manually set their Type on the individual Device page and click 'Configure', after which they were reporting switch status and power usage after just a few seconds. Is there some information I could provide that might be used to bake this in to pairing in the future?
Motion sensors, keyfobs, buttons - they all seem to be working!
Got questions about writing device drivers in my head now, but that will have to wait for another day.
Yes, please provide the fingerprint for the smartplug that was sent to the live logs via the default Device.
If this isn't available any longer, the get info command can be used with the Device driver
Is this what you need?
dev:3 2020-06-25 12:26:07.967 infoZigbee parsed:[raw:catchall: C216 00EF 02 02 0040 00 C475 01 00 0000 81 01 0000, profileId:C216, clusterId:00EF, clusterInt:239, sourceEndpoint:02, destinationEndpoint:02, options:0040, messageType:00, dni:C475, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:81, direction:01, data:[00, 00]]
dev:3 2020-06-25 12:26:02.962 infoZigbee parsed:[raw:catchall: C216 00F0 02 02 0040 00 C475 01 00 0000 FB 01 1F1699CB041C129802DDFF0100, profileId:C216, clusterId:00F0, clusterInt:240, sourceEndpoint:02, destinationEndpoint:02, options:0040, messageType:00, dni:C475, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:FB, direction:01, data:[1F, 16, 99, CB, 04, 1C, 12, 98, 02, DD, FF, 01, 00]]
dev:3 2020-06-25 12:25:57.911 infoZigbee parsed:[raw:catchall: C216 00EF 02 02 0040 00 C475 01 00 0000 81 01 0000, profileId:C216, clusterId:00EF, clusterInt:239, sourceEndpoint:02, destinationEndpoint:02, options:0040, messageType:00, dni:C475, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:81, direction:01, data:[00, 00]]
dev:3 2020-06-25 12:25:47.945 infoZigbee parsed:[raw:catchall: C216 00EF 02 02 0040 00 C475 01 00 0000 81 01 0000, profileId:C216, clusterId:00EF, clusterInt:239, sourceEndpoint:02, destinationEndpoint:02, options:0040, messageType:00, dni:C475, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:81, direction:01, data:[00, 00]]
dev:3 2020-06-25 12:25:37.893 infoZigbee parsed:[raw:catchall: C216 00EF 02 02 0040 00 C475 01 00 0000 81 01 0000, profileId:C216, clusterId:00EF, clusterInt:239, sourceEndpoint:02, destinationEndpoint:02, options:0040, messageType:00, dni:C475, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:81, direction:01, data:[00, 00]]
dev:3 2020-06-25 12:25:36.914 infoZigbee parsed:[raw:catchall: C216 00EF 02 02 0040 00 C475 01 00 0000 82 01 00000000CC32010000, profileId:C216, clusterId:00EF, clusterInt:239, sourceEndpoint:02, destinationEndpoint:02, options:0040, messageType:00, dni:C475, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:82, direction:01, data:[00, 00, 00, 00, CC, 32, 01, 00, 00]]
dev:3 2020-06-25 12:25:32.936 infoZigbee parsed:[raw:catchall: C216 00F0 02 02 0040 00 C475 01 00 0000 FB 01 1F1621CB041C129802DDFF0100, profileId:C216, clusterId:00F0, clusterInt:240, sourceEndpoint:02, destinationEndpoint:02, options:0040, messageType:00, dni:C475, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:FB, direction:01, data:[1F, 16, 21, CB, 04, 1C, 12, 98, 02, DD, FF, 01, 00]]
dev:3 2020-06-25 12:25:27.893 infoZigbee parsed:[raw:catchall: C216 00EF 02 02 0040 00 C475 01 00 0000 81 01 0000, profileId:C216, clusterId:00EF, clusterInt:239, sourceEndpoint:02, destinationEndpoint:02, options:0040, messageType:00, dni:C475, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:81, direction:01, data:[00, 00]]
dev:3 2020-06-25 12:25:17.888 infoZigbee parsed:[raw:catchall: C216 00EF 02 02 0040 00 C475 01 00 0000 81 01 0000, profileId:C216, clusterId:00EF, clusterInt:239, sourceEndpoint:02, destinationEndpoint:02, options:0040, messageType:00, dni:C475, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:81, direction:01, data:[00, 00]]
dev:3 2020-06-25 12:25:12.315 debuggetting info for unknown Zigbee device...
I know that there's a 'lock' mode (where the button on the top is disabled) and that the device also reports temperature information, though somewhat skewed given the warmth generated by the electronics.
I used to use a bunch of Python scripts to control these for a little while; that one I've linked to includes some information about the lock mode and other functions.
Just had to re-pair some plugs (they're being redeployed around the house) so here's a screenshot of it as a 'device' on the pairing screen.
@mike.maxwell Just let me know if there's anything else you need from these plugs.
Osram bulbs repeat xiaomi too, at least they did for my cubes. The only draw back is the osram bulbs themselves aren't stable on their own. I just ditched my last 6 osram halo style can lights for the cheap Sylvania rgbw bulbs form amazon, my cubes drop after an hour or so but my lights work. On the up side I can re-pair them by hitting detect zigbee and giving the cube a shake.
Okay, a few days in and I'm discovering a few things with my setup. I thought it worth documenting this in case any new or prospective UK users appear, because I'm certainly going to be singing this systems praises.
I ended up having a lot of success with the Xiaomi Aqara QBKG03LM and QBKG04LM wired wall switches (no neutral) and just my original AlertMe SPG100 UK outlets pictured above. They paired perfectly and worked reliably. However, the same couldn't be said for any 'sleepy' battery powered Xiaomi device; basically anything with a model number starting with WXKG. They all dropped their connections after about an hour or so.
On the advice of this thread I ran out and bought a bunch of IKEA Tradfri Repeaters. I reset my hub, moved my 2.4GHz WiFi to Channel 1, set Zigbee to Channel 25 and created a very simple network with one repeater close to the hub, then added a wireless wall switch. This worked and the wall switch stayed connected throughout the day, which had never worked before.
This success continued until I started adding the V1 devices again, at which point the battery powered Xiaomi Aqara devices became hugely intermittent and the V1 end point devices would drop off, sometimes all the way back to pairing mode, after about 10 minutes. All V1 motion sensors and buttons would initially work just fine, reporting motion or presses, but then abruptly stop responding.
This happened repeatedly, so I can only conclude that original AlertMe end point devices do not like sharing a network with Aqara ones. You may have more luck if you don't use any Xiaomi Aqara WXKG or MFKZ devices, but the good quality and comparatively low price means you're probably going to want to.
BTW, I also had no idea what "success" actually looked like for these Xiaomi Aqara devices. Basically, they should work on every button press with maybe a second or two latency (at worst) for the end point to be triggered.
Considering the amount of AlertMe gear I have, I'll be buying another Hub (when I can find one) which will exclusively deal with that kit and control both with the official Hub Link app. Because the UK AlertMe kit was built with security system use in mind I'll refresh the batteries in the SPG100 smart plugs and make a mini UPS for the Hub, so that side will continue to work during a power outage, as originally designed.
Overall I've been very impressed with this system, but even more so with the community here, who've been supportive and insanely quick to respond! Thanks, everyone.
Great to know it's working/ going to work for you 
. I suspected you may have a issue with the mixing and I think separation is the right way to go. With the new C-7 announcement I'll be getting 2 and doing just that so I can run the problem lamps and z-wave devices on one hub. Then ZigBee 3.0 and z-wave plus on the other.
Worth a little update; the cause of my instability (!) was actually down to the Xiaomi Aqara QBKG03LM and QBKG04LM wired wall switches I so highly praised above. Following the advice of @markus I removed them from the network and haven't had issues since.
I had to change network channel to prevent them reconnecting every time I put the hub into join mode, because for obvious reasons I can't turn them off. To go belt-and-braces I reset the hub, switched to channel 20, then connected two Tradfri repeaters, two WXKG03LM wireless switches, two WXKG11LM and one MFKZQ01LM cube.
When I was certain they were absolutely stable (as in, every press was received by the hub and they all checked in independently every hour) I added three Tradfri lamps. Still stable. Then added my AlertMe (Iris V1) motion sensors. Still fine. Added two AlertMe SPG100 outlets. All good.
Worst case scenario is I'll dedicate a second hub to controlling the wired wall switches, though there are some beta drivers I should try.
So apart from the wall switches I'm well on the way to a fully working system!
Currently missing are drivers for the AlertMe Power Clamp (an incoming mains usage reader which I can get partial support for using the "Iris V1 Outlet" driver), the AlertMe Lamp (a repeater with handy RGB LED status indicator) and the AlertMe Alarm Listener (which may be usable with the Button driver, I need to test).
Finally, there's a bug with the SPG100 outlet where it doesn't receive a fresh configuration after being powered off. It stays on the network when powered back on, but is uncontrollable until a configure event is sent to it. Perhaps yet another one for @mike.maxwell's list, but hopefully a quick fix.
When these power up they are supposed to send a specific command to the hub, when we see this we enable remote control. If we don't receive this command obviously there's no response sent.
Some of these networks/device combinations do a better job than others at this.
Download the Hubitat app
