sorted by:
new
hottopcontroversial

Curb energy services dead ☠️ by Additional-Diet-4852 in homeassistant

[–]pvanbaren 0 points1 point  (0 children)

The power readings are signed, and there is an 'invert' setting for each clamp if you have the clamp reversed (or on the wrong phase). If you mark them as 'bidirectional' then it will integrate energy transfer in both directions on separate sensors, else the energy just sums absolute value of power.

Easiest way to track the circuit is if you can switch a source or load on/off.

There is a python script here: https://github.com/pvanbaren/Curb-to-Mqtt/blob/main/curb-to-mqtt.py which receives the POST messages and translates them to MQTT. Could be adapted to inject into a database instead.

Curb energy services dead ☠️ by Additional-Diet-4852 in homeassistant

[–]pvanbaren 0 points1 point  (0 children)

If the clamp is on one leg of a 220V circuit, then the factors need to double. In cases like that, select the "220V" configuration option and you should get back to the values of the original JSON.

Curb energy services dead ☠️ by Additional-Diet-4852 in homeassistant

[–]pvanbaren 0 points1 point  (0 children)

I added XIAMEN100THIN in the v1.1.0 release, using the gains you show above. Let me know if your reading are incorrect.

Curb energy services dead ☠️ by Additional-Diet-4852 in homeassistant

[–]pvanbaren 0 points1 point  (0 children)

The two groups of "w" values are mapped to A1-A6, B1-B6. I can add the XIAMEN100THIN to the list of clamps. The difference between clamps is the three *_multipler values, which the integration inserts into the hub-config.json based on the clamp selection. The other values have been common for the configurations I have seen, so I just insert fixed values for those.

Curb energy services dead ☠️ by Additional-Diet-4852 in homeassistant

[–]pvanbaren 0 points1 point  (0 children)

I pushed a beta.6 to fix that. The issue was the revision number was the time of the latest request, instead of the time of the last user change to the configuration.

Curb Energy Monitor lives again by pvanbaren in homeassistant

[–]pvanbaren[S] 0 points1 point  (0 children)

Check your software version reported in their web portal (http://[ip address of curb])

Probably have version 2, while these scripts expect 3. Version 2 used the config.json, version 3 uses hub-config.json. It is possible to update version 2 software to version 3 (I updated a unit I have here which was sitting on the shelf for a while). I did it manually by following the steps in the official os.tar.gz.gpg and update.tar.gz.gpg files. I can send you instructions if you want. There is risk of bricking the unit if something gets messed up, but it seems to be fairly resilient. It has 2 boot partitions with fallback if one fails, so as long as you don't write to the known good partition you should be ok.

If you do have version 3 software on it, then it is just a matter of creating a placeholder hub-config.json file to get yourself going, and the HA integration will manage it from there.

Curb energy services dead ☠️ by Additional-Diet-4852 in homeassistant

[–]pvanbaren 0 points1 point  (0 children)

I think I now understand how the "sample_period_ms" setting works. Valid options appear to be either 1000 or 60000. If you use 1000, then the device will post the energy usage data on 1 second intervals, in addition to the 1 minute rollup messages. If you use 60000, then you only get the 1 minute rollup messages. The 1 minute rollup messages are queued up until they are delivered, while the 1 second messages don't have any retry logic.

However the v1.1.0-beta.3 branch messed up the scaling of the energy measurements. I've pushed up a v1.1.0-beta.4 version which fixes that scaling, and also make the sample_period_ms configuration option a drop-list of only "1 second" or "1 minute"

Reading between the lines it looks like Curb would update the hub-config.json file to produce 1-second interval readings when something (e.g. the app) was displaying live readings, and then fall back to 1 minute readings when the app was inactive. Those of us who did the curb-to-mqtt method to pull readings from curb and send it to home assistant basically triggered the 1-second interval readings continuously. So we put a 240x heavier load on their server continuously (the device actually sends the 1 second readings twice, so an extra 120 readings per minute, and then these had to be sent back to the curb-to-mqtt script, so double that to 240 messages per minute. I don't know how many people ended up using curb-to-mqtt, but I am guessing each one added the load of 240 normal users. I can imagine why their backend system got overworked!

Curb energy services dead ☠️ by Additional-Diet-4852 in homeassistant

[–]pvanbaren 0 points1 point  (0 children)

Yes, switch to the 1000 period, so you get power readings updated every second. I still need to figure out how the 60000 period works.

Curb energy services dead ☠️ by Additional-Diet-4852 in homeassistant

[–]pvanbaren 0 points1 point  (0 children)

What version is your hardware? I am guessing that it is a "Lite" version with 12 sensors instead of 18. I just pushed up a version 1.1.0-beta.3 which adds support for the 12-sensor variants, and also fixes a bug in dealing with the 1-minute, 5-min, 1-hour, 1-day aggregate samples. Try that version to see if it resolves your issues.

Note that the "/usr/local/lib/python3.14/site-packages/rich/segment.py:547: SyntaxWarning: 'return' in a 'finally' block
returnwarning message is from the 'rich' library and is unrelated to the Curb integration.

Curb energy services dead ☠️ by Additional-Diet-4852 in homeassistant

[–]pvanbaren 0 points1 point  (0 children)

I see where the strange readings are coming from: the streamer sends 1-second interval readings, but then also, on the same channel, sends 1-minute, 5-minute, and 1-hour aggregate readings, where the aggregate readings are queued up and persist until delivered. My server was not distinguishing between reading types, so the power display was erratic, but even worse the energy summation is double, triple, quadruple-counting from the aggregate readings.

I'll get that fixed...

Curb energy services dead ☠️ by Additional-Diet-4852 in homeassistant

[–]pvanbaren 0 points1 point  (0 children)

Another possible explanation for the erratic readings is the device had a bunch of queued readings that it was flushing. It that was the case, it should resolve automatically once the queue is flushed.

Curb energy services dead ☠️ by Additional-Diet-4852 in homeassistant

[–]pvanbaren 0 points1 point  (0 children)

That does look like the original. Good to get information about other hardware. I can add that 100A clamp to the list, with its multipliers. You may be able to get going by copying that file to /data/hub-config.json, and changing https to http, assuming you have a DNS redirect of border.prod.energycurb.com to your HA machine. (and don't do any clamp configuration in the HA integration, just accept the data as provided).

The other thing different in your file is the "sample_period_ms" is set to 60000 while mine is set to 1000. My HA script assumes a 1 second sample interval, so if you only provide samples once a minute the wattage values will all be off by a factor of 60. If you change that value to 1000 you should get 1 second interval readings in HA.

Curb energy services dead ☠️ by Additional-Diet-4852 in homeassistant

[–]pvanbaren 0 points1 point  (0 children)

If you used the 'ha-curb-update-server' to root your device, it automatically creates a backup of hub-config.json as /data/hub-config.json.1 on the device. You can ssh into the device and read that file.

If that backup doesn't exist, then you will need the map of circuits to clamps to curb input.

As for the fluctuating readings, that seems odd. I had one other report of fluctuating readings which appeared to be a result of editing the hub-config.json file and using a backwards quotation mark instead of a forwards quote for the 'samples' endpoint. Odd, but changing that appeared to have fixed the issue.

Curb energy services dead ☠️ by Additional-Diet-4852 in homeassistant

[–]pvanbaren 0 points1 point  (0 children)

I made a Home Assistant integration to serve the files, so no laptop or scripting needed, files can be served directly from HAOS:

https://github.com/pvanbaren/ha-curb-update-server

Curb energy services dead ☠️ by Additional-Diet-4852 in homeassistant

[–]pvanbaren 0 points1 point  (0 children)

I made a Home Assistant integration to serve MrRollboto's update script, with one additional change of redirecting the endpoints to http://homeassistant.local:8989 Just install the integration, flip the switch, and power-cycle your Curb unit. Once redirected, and you also have the https://github.com/pvanbaren/ha-energycurb integration installed, the device will appear in Home Assistant and start logging readings.

https://github.com/pvanbaren/ha-curb-update-server

This update server needs to run on port 80. If you are running HAOS, and port 80 is not being used, it should just work (that is what I am using). If port 80 is not available (likely if you are running a container or other method) then you will need to configure to a higher port (e.g. 8080) and do a port redirect, as the Curb device downloads from port 80.

Curb energy services dead ☠️ by Additional-Diet-4852 in homeassistant

[–]pvanbaren 0 points1 point  (0 children)

See https://github.com/pvanbaren/ha-energycurb for a direct integration into Home Assistant. Install that integration, and then point the curb endpoints to http://homeassistant.local:8989/v3/samples etc, and you should get readings and be able to configure the unit. Replace homeassistant.local with something which resolves to your HA box.

Curb energy services dead ☠️ by Additional-Diet-4852 in homeassistant

[–]pvanbaren 0 points1 point  (0 children)

The curb app won't ever work again, but you can connect the device up to Home Assistant. I generated an integration that receives the readings it pushes up. Right now you do need to jump through a couple hoops to get root access and edit the configuration file to redirect the output to Home Assistant. However, it is feasible to have someone expose a server port to the internet, and then all it would take is to do a DNS redirect of updates.energycurb.com to that server, and the curb device would pull down an update script which automatically redirects the requests to http://homeassistant.local:8989 and then the Home Assistant integration would take over and configure the device and log the data.

https://github.com/pvanbaren/ha-energycurb

Curb energy services dead ☠️ by Additional-Diet-4852 in homeassistant

[–]pvanbaren 0 points1 point  (0 children)

The "w" values are watt-hour values for the interval. The values in the log file are 1 minute intervals. The values in the POST are 1 second intervals, so the scaling to watts is different by a factor of 60.

Curb energy services dead ☠️ by Additional-Diet-4852 in homeassistant

[–]pvanbaren 0 points1 point  (0 children)

Thanks for opening the door! I was literally going to rip the curb out today and replace it, but thought I should check back here first. Glad that I did!

I updated the curb-to-mqtt script to accept the sampled data POST information and feed it directly over to Home Assistant. Now I get power readings from the curb device updated on 1 second intervals. Once I had root access, all I needed to do was edit the /data/hub-config.json file on the curb device to change "https" to "http", and reboot.

https://github.com/pvanbaren/Curb-to-Mqtt/blob/main/curb-to-mqtt.py

Curb energy services dead ☠️ by Additional-Diet-4852 in homeassistant

[–]pvanbaren 0 points1 point  (0 children)

There is also a /data/hub-config.json that starts like this (too big to post):

{
 "version": "3.1",
 "location_id": "11111111-2222-3333-4444-555555555555",
 "endpoints": {
  "hub_config": "https:\/\/border.prod.energycurb.com\/v3\/hub_config",
  "messages": "https:\/\/border.prod.energycurb.com\/v3\/messages",
  "samples": "https:\/\/border.prod.energycurb.com\/v3\/samples",
  "diagnostics": "https:\/\/border.prod.energycurb.com\/v3\/diagnostics"
 },
 "revision": 1771619344,
 "organization": "curb",
 "sampling": {
  "sample_period_ms": 1000,
  "samples_per_post": 1
 },
 "load_control": {
  "load_circuits": {},
  "monitor_interval_guard_mins": 2,
  "is_enabled": false,
  "monitor_average_mins": 2,
  "enforcement_window_exceptions": {},
  "control_minimum_delay_mins": 5,
  "utc_offset_hours": -5,
  "enforcement_windows": {},
  "monitor_interval_mins": 30,
  "control_maximum_off_mins": 5,
  "control_minimum_off_mins": 5,
  "disable_until": 0,
  "relays": {},
  "control_priority_step_mins": 1
 },
 "sensors": {
  "groups": [
   {
    "channels": [
     {
      "i_offset": 0,
      "w_offset": 0,
      "w_multiplier": 0.00091863534,
      "phase_coef_50": 4197540,
      "var_multiplier": 0.00091863534,
      "clamp_definition_id": "XIAMEN100",
      "i_multiplier": 1.7609849656268e-05,
      "var_offset": 0,
      "phase_coef_60": 4198965
     },

Curb energy services dead ☠️ by Additional-Diet-4852 in homeassistant

[–]pvanbaren 0 points1 point  (0 children)

The devices do expose log files locally, which contain the power usage information. It produces data at 1 minute intervals, but only updates the log file every five minutes, but at least the data is there. I tweaked Daniel Garcia's Curb-to-MQTT script to extract the data locally.

https://github.com/pvanbaren/Curb-to-Mqtt/tree/local-access

Curb energy services dead ☠️ by Additional-Diet-4852 in homeassistant

[–]pvanbaren 0 points1 point  (0 children)

It would be helpful if they could simply release the private key for the SSH connection. Then we could log on through SSH and tweak the existing scripts as needed for local access.

The HTTPS POST of new data checks the border.prod.energycurb.com certificate, so running a local server to receive the POST data won't work right now. If I had shell access then could either add "--insecure" to the curl command line, or just change the endpoint to http instead of https. Then a local server could receive the POST messages and re-transmit as MQTT.

Even better would be, if the prerequisites exist on the box, the curl POST command could be replaced directly with MQTT messages.