I was wondering what capabilities the USB stick has.
In particular, the types of Zigbee it can "see". It can't see Zigbee Light Link (nor can SmartThings), hence why I have the Philips Hue bridge.
My interest is in the fact that the smart meter installed in my house has a Zigbee SE (Smart Energy) transceiver on it, and you can (in theory) purchase a device like the Rainforest Eagle 200 and talk to it (if you get your device MAC address registered with your energy provider). It looks like a really good (and direct) way to get accurate energy readings. They also have developer support which would integrate nicely with the hub (https://rainforestautomation.com/support/developer/)
Anyway, I guess I'm just asking because I can't find any documentation. I'm also having a very hard time getting any vendor to supply/ship the Eagle-200 device to me in Australia.
Gday @robert1. I too are very interested in connectivity to the smart meters here in Victoria.
I was going to purchase a single phase Aeotec smart energy meter to get this data as it is supported by Hubitat. After searching for an a Australian version for a while i decided to contact Aeotec direct. I was advised they will not produce any more AU versions unless significant interest in them .
So i am back to looking into the Ausnet Smart Meter already installed in my meter box.
All i am looking for is instantanious reading (i have solar) of +/- Kw. This should not need another third part device. I have not researched this but would expect zigbee hubs can connect to zigbee se devices if a correct DH is used? I was thinking of registering the mac address of the hubitat hub with Ausnet (not sure about security) and test some of the standard DH's.
Am i way off here?
Also, overall, how is your hubitat experience and AU device intergration going?
Not sure I follow. The HUSBZB-1 stick the comes with US/Canada versions of Hubitat can handle both HA and LL libraries. There are Hub versions for other regions with the correct Z-Wave frequencies via a separate stick, depending on the region, and separate Zigbee stick is also included. Seeing that you are in Australia and an owner, I'm guessing you can now confirm this. There is also now Hue Bridge Integration if you want to keep your bulbs paired with the Hue Bridge and control them from Hubitat (this is my choice), or you can reset your Hue Bulbs and pair them directly with Hubitat via the HUSBZB-1 stick. The important thing to remember is, you must reset your Hue bulbs, and that requires either a Hue Dimmer or a Lutron Connected Bulb Remote, which was only sold in the US and Canada, and is now discontinued.
I don't believe this is correct. I'm under the impression that the SE libraries must be part of the firmware. Perhaps @JDRoberts could shed some light on this question?
You're talking about zigbee "profiles." Not "types." See the following:
Part of the specification is that all certified devices using the ZLL profile will fall back to a ZHA profile when joined to a ZHA coordinator. Both smartthings and hubitat are ZHA coordinators. They don't have quite the same capabilities, in particular the 2 ZHA hubs will not do a touch-link join, but it's the reason why many devices using A ZLL profile can also be added to a zigbee network run by a ZHA coordinator.
Zigbee smart energy is a very different type of profile, it doesn't even use the same addressing scheme. It is used almost exclusively by utility companies, with a new niche in electric vehicles.
It is significant that while zigbee green energy ( such as used for the Hue tap), for example, is included in zigbee 3.0, zigbee smart energy will continue to be a separate profile.
So the short answer is that zigbee smart energy is not compatible with the zigbee profile that hubitat uses.
(BTW, by "Hue hub," I assume you meant "hue bridge" since there is no hue hub device.
There is also a completely separate issue with regard to the smart meters, which is that under most zigbee application profiles, a device can only be joined to one coordinator. ( there are a few manufacture proprietary profiles which do allow for multiples.)
Anyway, since smart meter belongs to your utility's zigbee network, it's not available to join any other network even if that other network did support the smart energy profile.
The rainforest eagle device works by joining to the utility's network, which is why you need the utility's permission. Then it makes the data stream available over the Internet. There are a few people using that one with smartthings, but they aren't using its zigbee capabilities. Just the open API. So it never connects directly to the homeowner's home automation hub. It's a cloud to cloud integration.
( and you won't be able to connect your hubitat hub to your utility's zigbee network because the hub doesn't support the SE profile. It all comes back to the same thing: zigbee allows for a number of different profiles, and they aren't all compatible with each other. )
Ah, caught me on the hub technicality again! I wrote bridge the second time, but made a mistake the first. Anyway, I fixed it, for your reading pleasure
Thanks @SmartHomePrimer and @JDRoberts for your assistance on this one. Great detail and appreciate your time spent on this.
I am not set on Aeotec but this is the only one I have seen that works with hubitat.
Is anyone aware of anything that may work (z-wave or zigbee)? Alternativly I will have to keep at Aeotec to supply the AU version of the âhome energy meterâ.
I would just check with locals using solar energy to see if they have any knowledge of meters that can report via Wi-Fi using LAN (not internet). That would be the easiest way to hook something in and stay local.
I know there are some like Sense for the US that even have IFTTT channels. But I'm not familiar with what's available in Australia.
I just mentioned solar energy because most people who have it also do whole house monitoring of some kind.
Thanks @JDRoberts. I do have whole house monitoring via a Fronius smart meter. The smart meter is in my meter box and the solar inverter is some 50m away in my shed. This smart meter is linked to a Bluetooth dongle via modbus (I think) with the other Bluetooth at the inverter. Trying to get this data from any of these sources is way out of my league and data from the internet has a couple of minute delay.
A seperate device is the only way. I may look into the rainforest eagle as @robert1 has mentioned in another discussion. I will also talk with my power company to see if there are any other options. Thanks.
@doctorkb I have the original Eagle connected to Hubitat. My driver uses the local API to retrieve the current power usage every 20 seconds. Iâm not sure how much of the API has changed with the newer model. In order to use the local API I had to disable cloud access (why they required that, who knows). I found that requesting data from the Eagle so often caused it to frequently lock up, so I have it connected to a lamp timer and have it power cycle every few hours. The whole thing has been a pain, but it otherwise works.
Thanks... I've got it reporting through OpenHAB now so it isn't the end of the world. Just would be nice, but not worth having to reboot things that often.
In case it's useful for anyone here is my code. There is an app and a driver. The app creates a child device. I added a feature that will automatically power cycle an outlet that the Eagle is plugged into when it locks up.
Thank you for sharing, @augoisms . I'm finally trying to complete moving everything from my Vera3 and my Rainforest Eagle is one of the last pieces. I entered all of the information in the app and see the child device created, but it doesn't seem to work. It can't refresh at all. I tried the "MAC" from the bottom of my Rainforest Eagle (16 hex digits) and also the network MAC Address (12 hex digits). Neither way works.
@kleung1 Status 401 means unauthorized, so youâre at least reaching the Eagle. I would stick with the hex version of the MAC 0x{ADDRESS_ON_BOTTOM}. Have you disabled cloud access on the Eagle? I vaguely remembering this being a requirement.
@kleung1 I was looking at my old ST posts on this, and I mentioned needing to disable both "remote management" and "security."
Also, it looks like someone wrote a ST app/driver for a cloud api version, so if you can't get it work you could try and port their code. The Eagle has unfortunately been difficult to deal with. Good luck!
Thank you so much @augoisms. I'm looking into this. It's difficult to decipher what's happening because while I'm not able to log-in to the Eagle locally, I can view it on https://rainforestcloud.com/
The Rainforest Eagle "Cloud" service was Bidgely, which seems to be no longer supported, so I kind of thought the cloud is disabled. I disabled it anyway, but no change. Is being able to connect via rainforestcloud.com in a way a "cloud" service? Or is this the "remote management" you're referring to?
I'm going to give the ST app/driver a look and see if I can port it to try. Thanks for the pointers!
@kleung1 The cloud settings are different. Open up the first âEagleâ section, click the cog, and then uncheck remote management and security. This will obviously disable cloud/remote access, but you can still access the local url (eagle-{CloudId}.local).
Fair warning, youâll likely find your Eagle locking up frequently, so youâll definitely want it plugged into a smart outlet.
I came across a Home Assistant thread where people were having similar lockup issues as I have experienced with this polling method (local or cloud API). Creating a custom cloud provider that the Eagle pushes data to seems to be the way to go. Iâm tempted to write a new driver that supports this.
I just went through this setup a few minutes ago and happy to share my experience. I used the mac address from the bottom of the device, lowercase, no spaces.
Also, like @augoisms said, uncheck the Allow Remote Management and Enable Security boxes.
I ended up using a custom script on my Linux box to query the Eagle once per minute. It isn't instantenous demand (but neither was OpenHAB) -- it just gives an idea of when the big sucks (furnace, heaters) are on, as well as the ongoing meter reading. This made more sense to me since I'm just using it to graph usage -- not automate anything.
Since switching to this, I haven't had to reboot the Eagle once. Could the HE/ST implementations not be closing their connections properly?
.
