NEW: Aeon Home Energy Monitor v2 Device

I dont know!! Maybe you can ask on the aeon website.

Ok thank you

New Apple app broke this DH… both iPad and iPhone.

something went wrong
We can’t load your screen right now

I am seeing the same thing. I sent in a support request but I have yet to receive anything back. There is a thread about the update changing something in the Action Tiles and some suggested changes. I looked at the DH briefly but it didn’t seem as straight forward as the thread implied so I switched over to another DH. “Aeon HEMv2 Gen2 - AMR Basic Edition”

I have an app I wrote that sends me nightly power usage data warns of high power usage if not home and resets the Meter each month, so I had to modify it slightly to get it to work with the new DH. The basic one doesn’t look as nice but it works.

I haven’t been actively maintaining this, and there are several newer forks of my work around. I took my HEMv2 off line several months ago.

That said, if you can share pointers to any discussions on fixes, I’ll take a look and see what I can do…


@Brad_ST posted this on the Aeon devices…

Hope this helps :slight_smile:

1 Like

It looks like tile definition in the DTH is invalid. Specifically, backgroundColors.value is expected to be a BigDecimal and not a String. I’m not sure how this ever worked, tbh, but if you change this to this

    [value: "0", 		color: "#153591"],
    [value: "3000", 	color: "#1e9cbb"],
    [value: "6000", 	color: "#90d2a7"],
    [value: "9000", 	color: "#44b621"],
    [value: "12000", 	color: "#f1d801"],
    [value: "15000", 	color: "#d04e00"], 
    [value: "18000", 	color: "#bc2323"]

That should fix your problem.

Edit: Looks like @jkp beat me to it :slight_smile: well done :clap:

Edit 2: Looks like a PR was opened Dec, 2015, but never merged:

1 Like

No, we were tying at the same time. But your display looks better

Thanks guys I went through and made your changes and it is working again. I also changed the ValueTiles for amps and volts as well. When I just changed the Watts section it at first did not work.

I then went back and changed the amps and Volts but I had also commented out a section in an earlier attempt to get it to work and forgot to put that back in in my first attempt. So maybe it did not work because of that commented out section.

Anyway it looks like the amps and volts sections should be updated as well, and it is working with those updates.

1 Like

I merged the pull request to fix this…I can’t test it myself because my HEMv2 won’t pair with SmartThings today…will try again over the weekend.

Sorry for the inconvenience…

1 Like

I also deployed a change to production about an hour ago that should prevent crashing or visible errors. The downside to my change is that invalid backgroundColors will just be ignored. The upside is that I think they were being ignored in the mobile apps before this bug appeared. So we’re back to ignoring you :wink:

It’s good to fix your DTHs anyway, but unfortunate that you were forced to do it. Please let me know if you are sill experiencing any issues and I’ll do my best to track it down.

Thank you to everyone that helped to track this one down, and helped others fix their DTHs.

1 Like

Could that change possibly have caused standardTiles to start displaying the “state” as the “label”? All of a sudden all of my standardTiles that did not have a label are displaying the state text within the tile. This really screws things up…

Do you mean A or B in the example below?

    standardTile(name: "someName", attribute: "someAttribute") { // A. no label here?
		state "someState" // B. no label here?

B - never used to display anything, now is displaying “SOMESTATE”

And adding label: '' doesn’t have any effect

Ok, I think I see where that is happening. I won’t be able to get anything out this weekend, but I should be able to on Monday. Thanks for the help.

Bummer - it really screws up my Ecobee Thermostat Suite, because it displays the (somewhat meaningless) gibberish states I use to select from the 20 or so Thermostat Operating State icons I display.

But Monday is better than never - so, thanks!

(Now, if we could just get the Android thermostat multiAttributeTile to display the same operating state text in the bottom row as the iOS one again, AND maybe get icon sizes and font sizes to be the same on both iOS and Android, THEN I’d be a happy camper!)


Actually, if you’re willing to do some hacking, you could try something like unit: '', label: '${unit}'. Notice the single quote and not the double quote. The mobile apps should parse anything within ${} as a variable on state. What’s currently happening is that label is being defaulted to label: '${name}', which ends up parsing into the label. So if you’re not using unit or labelIcon or some other rarely used attribute on state, you might be able to get an empty string to render. This is of course pretty hacky, and will ultimately not be needed beyond this weekend, but that’s how it works. I am a little confused as to why label: '' is getting overridden, but I’ll dig in and figure it out.

As for the icons and fonts in the mobile apps, I can file some bugs, but I can’t promise that they’ll get prioritized as quickly as you might like.

On the labels, I’ll just wait for it to go back to the way it was. For some states, I DO specify a label, others I don’t.

I will note that something has caused the thermostat MultiAtributeTile to show the SmartThings icon instead of the water drops icon for the Humidity display…

On icons and fonts, it really makes SmartThings look shoddy on Android, and given that Samsung is deeply invested in Android, I’d think someone would want to put in the extra effort to make it look as good as iOS - with the exception being that the font used for values doesn’t auto-scale on iOS as it used to, so the text always seems to exceed the size of the icon (like trying to display “Hum 45%”).

Finally, the worst Android offender is the Thermostat multiAttributeTile - and it is aggravating because I managed to get it prioritized and fixed once, but it reverted recently. It’s a bit complicated, but here’s the deal:

On iOS, the text at the bottom/middle of the box will say “Heating at 70” when the thermostat operating state is “idle”, and “Heating to 70” when the thermostat operating state is “heating.” I use this to display the ACTUAL temperature that will cause a demand for heat, as in “Heating at 69.5” (my Ecobee Suite allows one to choose how many decimal points are displayed for all temperatures). On Android, this currently shows “Heating to 69.5” - it always says “Heating to ##” (note, all this is also true for “Cooling at/to”…). This one I’d REALLY like to get fixed (again)…

Thanks for listening!

How do you know if it’s v2? I’m looking at this one…