No idea what’s happened here and grateful of any ideas on how to fix it.
I think it is the consequence of a recent HA update.
The bottom three inputs are new. The top one has not been duplicated and is still mapped through to the feed fine.
I think I have sorted it. Clicked on the spanner icon for the three that did not have the log icon and used the ‘add to process’ dialog to associate them with the existing feeds. Then I deleted the original three that became ‘n/a’. Here’s hoping I haven’t lost any data.
… go nowhere. The value just sits there until another comes in and updates it, but until you log the data to a feed, nothing at all happens, it is not used anywhere. If you add process steps, then these are executed, but unless there is at least one “Log to feed” or an implied “Log to feed” where you have a step which writes to a feed, e.g. “Power to kWh”, the data is never used or saved.
So unfortunately, your screenshot shows no data has been received recently by the upper 3 inputs, so from the time the data was more than 10 s old on those inputs until you added logging on the 3 lower inputs, all the data has been lost.
1 Like
I did not make any changes to my Emoncms History YAML configuration and the three new inputs appear to have identical names to the original three. I wonder what changed in HA to cause my local Emoncms to create new inputs?
I can’t answer that one, sorry.
The new names must have looked different to the machine even though they appear the same to us. (Or possibly more accurately, by the time the name makes it to the Inputs page, it’s presented the same.)
1 Like
Hello @LeiChat Can you remind me how much flexibility you have in defining the Emoncms URL and API used to post the data in the HA integration? If you use /input/post?fulljson= instead of ?json= or data=, this should fix this issue.
This issue which I’ve only recently appreciated is due to the way the white spaces are treated in the decoding of json data using the non “fulljson” options.
Basically if you use fulljson:
{"P1":100, "P2":200}
results in two inputs “P1” and “P2” as you would expect.
But if you use data= or json=, these use the json-like decoder which can decode strings that look like this:
P1:100,P2:200
but if the data is actually json as above, with that white space after the comma, the json like decoder first removes the brackets and double quotes leaving:
P1:100, P2:200
and then it splits by comma and colon leaving: “P1” and “ P2” (notice that leading space).
On emoncms.org I have modified the code to trim all input names to remove any leading spaces and at the same time I removed all existing leading spaces from configured inputs so that I didn’t break existing configurations.
I haven’t pushed this change to the main emoncms branch yet as it’s not as easy to manage the migration process in a way that would not break existing configurations with leading white spaces. Perhaps I should make that change anyway, the number of systems likely affected by this is relatively small and it would be good to have a more robust and consistent behaviour.
The easy fix in the mean time is to use the “fulljson” parameter in the the API call.
2 Likes
In the HA configuration for the integration, I am just specifying the following URL:
Emoncms History - Home Assistant
I have had a quick nose at the GitHub repo but cannot spot where it may be appending the /input/post API path you mention. Maybe the code owner @alexandrecuer can confirm?
There is an issue open on that, I presume it is the same problem
https://github.com/home-assistant/core/issues/151959#issuecomment-3276215771
The previous version of the integration was sending a false json payload
So maybe replacing line 67 by this could solve the problem
```
if conf.get("legacy_mode", False):
payload = ",".join(f"{key}:{val}" for key, val in payload_dict.items())
await client.async_input_post(f"{{{payload}}}", node=node)
else:
await client.async_input_post(payload_dict, node=node)
```
But as I cannot test, I am not sure. If I could reproduce and test this I could submit a PR
I add just a pair of inputs concerned, with short names and when i started using the new implementation, i add no problem with the processes.
@LeiChat : the input/post API path is in the external lib, using an external lib is required by the HA team.
1 Like
maybe someone could test if this solves the pb….
if using the supervised installation of HA, use the terminal addon, connect to the container running homeassistant, and edit the __init__.py file :
docker exec -it homeassistant bash
cd /usr/src/homeassistant/homeassistant/components/emoncms_history
apk add nano
nano __init__.py
add vol.Optional(“legacy_mode”, default=0): cv.positive_int,to the CONFIG_SCHEMA,lie30
then replace line 67 by:
if conf.get("legacy_mode", False):
payload = ",".join(f"{key}:{val}" for key, val in payload_dict.items())
await client.async_input_post(f"{{{payload}}}", node=node)
else:
await client.async_input_post(payload_dict, node=node)
Then :
- save the file, exit the container and the addon,
- add
legacy_mode:1in your emoncms_history yaml conf - and restart homeassistant…..
I will try to test but I need to recreate an old install, I will take homeassistant 2025.7.0
What am I looking for when testing, please?
That’s a good catch.
Ideally, the integration should send fulljson (i.e a valid JSON string) by default to emoncms I’d suggest.
The problem is json isn’t 
Actually I think there is no bug with the new integration code.
Anyway, I submitted a patch to keep the ability to use the old payload string, through a legacy_mode var in the yaml :
Yes, the legacy format did have {} but, if you only ever send data as a validated JSON it should be fine.
I think this code has the potential for generating non-valid JSON.
The string should be in the format {"power1":100,"power2":200,"power3":300} (not the position of the quotes). There is json.dump in Python.
Have you checked the string you send validates as JSON?