Brultech GreenEye Monitor and ECM-1220/1240 integration

This custom integration replaces the built-in greeneye_monitor integration (for which I am the code owner) with a number of fixes and enhancements:

  • UI configuration instead of YAML
  • Energy dashboard support
  • ECM-1220/1240 support
  • Doesn’t crash when a DashBox is involved
  • Chatty entities disabled by default
  • Configuration entities for packet interval and CT type/range (only for monitors that are directly on the network, not via DashBox)
  • Various performance and stability improvements

To install:

  1. Install HACS
  2. Make a backup! If you decide you don’t like this version, restoring from the backup will be a better way to clean up than simply uninstalling the integration.
  3. Add this repository to HACS and download the integration
  4. Existing users of the built-in greeneye_monitor will be migrated automatically; new users add the integration via the UI and it will discover monitors as they send packets

I plan to remove the greeneye_monitor integration from core and focus my future efforts on this custom HACS integration.

Let me know how it’s working for you! Report issues here: Issues · jkeljo/hacs-greeneye-monitor · GitHub.

1 Like

I’m thinking about getting a 1240 with a dashbox. Can the integration pull directly from the dash box via it’s ethernet or do I still need the 1240 on the network too with their rs232 to ethernet adapter?

Thanks!

I don’t have a DashBox, but my understanding is that they can be configured to forward to another address all packets that they receive from attached monitors. If you set it up to send those packets to your Home Assistant instance, yes, this integration will receive them just fine.

There is one small caveat. When the ECM-1240 is directly connected to the network, this integration lets you configure the CT types/ranges and the rate at which the ECM sends packets. That doesn’t work when there’s a DashBox in the mix, because the DashBox only forwards communication from the ECM to Home Assistant and not the other way around. I suspect that’s not a major issue, since you can just use Brultech’s software for configuring your ECM.

1 Like

Has the integration been removed from Core ? I noticed that it stopped working in my setup but I wasn’t paying attention when upgrading core so I can’t tell if it’s related or not.

It hasn’t been removed, but the core integration is broken in the latest Home Assistant release because of the Python upgrade (Greeneye Integration broken in 2023.6.0 · Issue #94211 · home-assistant/core · GitHub). The HACS integration works fine, though.

Has anyone made a walk through on how to integrate this with Home Assistant? I have 2 Gems, but I’m completely new to home assistant and yaml.

Not to my knowledge, other than the instructions above and in the GitHub repo. One nice thing about this integration relative to the built in one is that you don’t need to mess with YAML for this one. You do need the Home Assistant Community Store (HACS), though, and getting that does require installing an add-on and logging in over SSH.

1 Like

Still work in progress, I did get it downloaded from HACS, still trying to figure out how to get the gems or dashbox to send info to HA. I dabbled with influx, and that was a dead end for me. Thanks for the reply. Hopefully I can get some traction this weekend.

jkeljo thanks so much for creating this integration. I have been a long-time user using the core version and like you pointed out, that system was broken with recent updates in HA. I stayed with the older version of HA for months prior to biting the bullet to make the upgrade.

Setting up the HACS version of this integration is very straightforward and was completed as a conversion from the existing YAML configuration. However, I am hoping to get some guidance in that I can’t seem to get the pulse counters to work in this version: rate or totalizer (pulses).

I have just created a new test environment of HA and completed a clean install of the GEM integration with hopes that with a new, non-converted, integration might correct my issue. After the install, the energy, power, as well as the amp channels, as well as volts all work. I Enabled the Rate ID entity but it still only states ‘unavailable’. Also, the pulses do not update at the expected thirty-minute period. I can, however, restart HA and each time HA is restarted the pulse counter updates to the current value in GEM.

Below is a snip of what I am seeing. Also, in Attributes the Pulses value is the actual value in the GEM and when multiplied by the pulse factor I entered for the channel it can be confirmed that the counter 1 “Water” value is correct although it states ‘pulses’. It should be gallons but I do not know where to change the units of measurement. I did review the Configuration section of the integration, but I can only find the ability to change the pulses per time option (per second, minute, hour).

I am sure I have something incorrect so any guidance would be greatly appreciated.

Thanks, Brian

Pertinent log entries:
2023-08-01 06:20:48.966 WARNING (SyncWorker_2) [homeassistant.loader] We found a custom integration hacs which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2023-08-01 06:20:48.967 WARNING (SyncWorker_2) [homeassistant.loader] We found a custom integration greeneye_monitor which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2023-08-01 06:26:33.093 WARNING (MainThread) [homeassistant.components.sensor] Entity sensor.gem_1000199_pulse_counter_1_water (<class ‘custom_components.greeneye_monitor.sensor.PulseCountSensor’>) is using native unit of measurement ‘pulses’ which is not a valid unit for the device class (‘water’) it is using; expected one of [‘gal’, ‘ft³’, ‘CCF’, ‘L’, ‘m³’]; Please update your configuration if your entity is manually configured, otherwise report it to the custom integration author.
2023-08-01 06:26:33.106 WARNING (MainThread) [homeassistant.helpers.entity] Entity None (<class ‘custom_components.greeneye_monitor.sensor.PulseCountSensor’>) is implicitly using device name by not setting its name. Instead, the name should be set to None, please report it to the custom integration author.
2023-08-01 06:26:33.109 WARNING (MainThread) [homeassistant.helpers.entity] Entity None (<class ‘custom_components.greeneye_monitor.sensor.PulseCountSensor’>) is implicitly using device name by not setting its name. Instead, the name should be set to None, please report it to the custom integration author.
2023-08-01 06:26:33.111 WARNING (MainThread) [homeassistant.components.sensor] Entity sensor.gem_1000199_pulse_counter_4_water (<class ‘custom_components.greeneye_monitor.sensor.PulseCountSensor’>) is using native unit of measurement ‘pulses’ which is not a valid unit for the device class (‘water’) it is using; expected one of [‘gal’, ‘ft³’, ‘CCF’, ‘L’, ‘m³’]; Please update your configuration if your entity is manually configured, otherwise report it to the custom integration author.

If you had counted_quantity and counted_quantity_per_pulse in your YAML, the migration should have picked that up and applied it to the pulse counter entities that it created. (If you didn’t, you can actually go add it to the YAML now and the integration should pick it up; it re-imports the YAML if it exists on every startup.)

For setting it up from scratch, there should have been a step in the config flow where it asked you to configure the units for the pulse counters.

It looks like the one pulse counter I have in my own setup is also not updating. Looking over the code I don’t immediately see the cause; I’ll look into it further.

Those other log messages I hadn’t seen before; it looks like those are new in HA 2023.7, which I haven’t upgraded to yet. I’ll see about making those go away while I’m looking into the pulse counter thing.

Thanks for looking into it!

I was doing a clean install on my test HA and did not add the YAML config info intentionally so I could confirm that was not the cause of the pulse counter not working. I now added the config info and like you stated and upon restart of HA the units of measurement and scaling was corrected.

There is a pop up upon conversation (in my case simply adding the config info in YAML):image

Is it advisable to go ahead and leave the configuration info in the configuration.yaml? And, if so, in the event the scaling or units of measurement need to be modified, just change it there?

Finally, the 30-minute update for the pulse counter is a bit on the longer side than what I would want. Using the original GEM setup, I have stored GBs worth of high-speed (10 second) data on my system, so I am not worried about worried about excessive data. Can this be reduced? I would prefer a sample rate at 1 minute if possible.

Thanks again…

Hmmm, so when setting up the integration fresh with no YAML, once you’ve configured your GEM to send packets to the correct port on your Home Assistant machine, you should have seen an option to configure a new monitor appear in the integrations page:

Part of that config flow prompts for information on each pulse counter, including the unit:

Did that not happen for you?

Personally I wouldn’t recommend relying on the YAML being present; if this ever does get integrated back into core the YAML capability will eventually go away. Unfortunately, though, in Home Assistant today the only way to re-run the configuration flow is to delete the integration and re-add it, which will forget all customizations you’ve made to existing entities (like renaming them). I added an issue in my repo to address this at some point: Allow changing pulse counter configuration after creation · Issue #30 · jkeljo/hacs-greeneye-monitor · GitHub

Regarding the update interval, I can look into making that configurable, but I’d like to first understand your use case. The pulse rate entities update as fast as the GEM sends data packets; it’s only the pulse count entities that are throttled. (They’re throttled so that the default setup can work with the HA energy dashboard without users having to get involved with InfluxDB and such.) Is it enough for you to have the instantaneous pulse rate on an every-10-seconds basis?

As a fresh install it did not auto discover the GEM even when packets were being sent to it. Many other integrations were discovered immediately but after waiting for 15 minutes I just went ahead and just manually added the GEM via the Add Integration button. Once I started the installation of the GEM integration everything came up like you stated. I suspect in my previous post the snips were from a second or third iteration and I got in a hurry and did not properly configure.

Upon installation this is how it was displayed:


Once I selected the new GEM Integration it displayed the snip below. It has a Discovered and Hubs section with Configure for both. I selected the Configure button in the Discovered section but I could see the Hubs section might be confusing (it was for me). Maybe the Hub section is for those with multiple GEM or ECM units

On the update interval. The electrical channels are being displayed and stored at the native GEM configuration for the Energy and Power. I am currently using the Energy value (KWh) for the Energy monitor, and it is being displayed and stored at the GEM packet speed. Maybe I could use the Power value, but I have not tried that. For the pulses (water), I followed that same approach in the older installation, and it worked well. Do you think I would be able to use the Rate for input? Once the pulse counter issue is corrected, I can test more.

Thanks again…

Right, it makes sense that you’d have to add the integration first, it doesn’t yet attempt any kind of auto discovery. (Most of the methods of discovery available don’t apply to GEMs, unfortunately.)

So you used to pull energy and pulse counts out of the extra attributes on the power and pulse rate sensors in the core integration? Those special attributes are still present on the power and pulse rate sensors in this version (which are updated as fast as the GEM sends them), so you could still do that while you wait for me to make the throttling on the new energy and pulse count sensors configurable.

I just fixed the issue where pulse counters were not updating at all, thanks for pointing that out.

Thanks for being so responsive! Completed the update and all is good. I have one pulse monitor providing values in GPM while the other is GPH and both now providing values in line with expectations.

I have the hacs-greeneye-monitor installed and configured for port 8000, on Dashbox I configured Packet Forward to the HASS IP on port 8000. Should this configuration work?

Hello there! I’m on the verge of buying a GreenEye monitor and have several dozens of sensors to input. Is this add-on still maintained? I’d like to contribute where I could.

Yep! Still maintained and in active use.

1 Like

I can’t find the info anywhere, but does this new version support multiple greeneye monitor? I imagine just each greeneye monitor using a different port to send the data?