I removed the blueprint YAML in the first post to prevent this issue.
@pCharden Is adding the blueprint from the button (straight from GitHub) and restarting HomeAssistant working?
Is your home-assistant installation able to reach out to the internet?
Hi Dirk,
Yes I have PVOutput electricity data uploading from homeassistant without issue from automations. The first automation config for this used the curl command used here, and I could not get it working, along with others who moved these to using a restful command.
Home Assistant is running in a docker container if that makes any difference?
Positive. I imported the blueprint by the button and restarted the RPi.
when i try to save the automation, i receive this error:
You are missing the ID, each entity must have a unique ID. Either it is generated when filling out the blueprint during import. Or you need to create a name for it, see below example, mine was an autogenerated number
Hi @danwnz
Running in a docker container is no issue, Home Assistant runs (almost) always in a docker container.
Is shell_command.curl_get working correctly? This can be tested with, for example, the following service in the developers tools:
service: shell_command.curl_get
data:
url: "https://ifconfig.me"
If correct, the outlput shows your public IP after stdout.
Yeah this is not working, getting time out. thanks so much for the tip for testing this.
Now I have a huge process of elimination for this, I did already try to rule out nextdns.
I suspect if it is trying a return path (confirmation) if on port 443 or 80 this is being intercepted by my Unifi router, if it stays within any other ports then its fine.
Just have no idea how these services work through the internet from within homeassistant
Hi @danwnz,
That’s progress. Let’s see if DNS is a problem.
Do you also get a timeout if you do the following?
service: shell_command.curl_get
data:
url: "https://8.8.8.8"
Hi Dirk,
Yes still timing out at that.
Below is my home assistant network config, each URL has a full SSL certificate configured in the configuration.yaml
The docker container is using the deployed using the host network, which is able to communicate to each device across my 5 vlans.
I have multiple network only devices updating information via the internet without any issues, also a mentioned before I have an automation updating information to PVOutput every 5 minutes, I could not get this to work with curl either so was converted to use Restful command.
Hi @danwnz,
That’s strange.
You could remove the curl_get config, reboot, add it again and reboot again. This could resolve an error.
Please check if your config is correct before adding it again.
Hi Dirk,
I have tried this, and still the same issue exists, logs are very vague so not helpful for troubleshooting, seems strange to me that just this curl service doesn’t seem to be able to communicate over the internet, when I have large numbers of devices that are reliant on the internet, including pvoutput update that is posting over the internet.
The only thing I can think about is that part of this config listed in the logs below has issues outside of the usual config directory, but I am not sure If I can delete this and restart to have it recreate them again?
Snippet from log
Logger: homeassistant.components.automation.wunderground_uploader_2
Source: helpers/script.py:485
Integration: Automation (documentation, issues)
First occurred: 3:43:51 PM (1 occurrences)
Last logged: 3:43:51 PM
WUnderground uploader: Error executing script. Unexpected error for call_service at pos 1:
Traceback (most recent call last): File “/usr/src/homeassistant/homeassistant/components/shell_command/init.py”, line 92, in async_service_handler stdout_data, stderr_data = await process.communicate() ^^^^^^^^^^^^^^^^^^^^^^^^^^^ File “/usr/local/lib/python3.12/asyncio/subprocess.py”, line 201, in communicate stdin, stdout, stderr = await tasks.gather(stdin, stdout, stderr)
I have done some tests from the docker terminal for homeassistant, and curl doesn’t work from here, are there any other prerequisites? curl is definitely there wget works without issue so not network outbound issue.
Curl does work natively from the primary NAS host, just not this homeassistant container, examples of basic tests from docker HA terminal
I have all of this time been experimenting and trawling through articles like a mad man, boy there is a heap of reports of issues with curl running. I have come across an article that looked promising --net=host problem is I have no clue where this needs to be added, but have a little success.
Below is the output of a manual automation run, which times out after 60 Seconds (second screen shot), if I grab that url and paste it in a browser it work flawlessly.
Now if I add the --net=host somewhere where I though it could be appropriate in the and does error out as shown in the image below, the automation then runs to completion, but does not update wunderground as I believe it has changed the output by putting “” around the URL second image shows this, and third image shows completion notification but not uploaded to wunderground
I deploy the HA container through the GUI in docker package on a synology nas, and can see that this --net=host is normally added during a terminal window deploy.
Does anyone know if this can be added after the fact, where it would need to go? I would have thought also that the host default docker network would have this switch
Hi @danwnz,
That looks like an solution! I didn’t know the docker host could influence the result.
If you need to add --net=host, it should be done in the container.
As far as I know, you cannot set the network type in an existing container.
You need to recreate the container from the UI and set network to host (this is probably bridge by default).
Hi Dirk,
Thanks so much, I will need to redeploy my container, I had been previously using the first example on the HA build page provided by home assistant, I guess that gui deploy method does not add this.
Hi @danwnz,
You used this page I suppose? That also mentions the correct network settings for setup by UI.
Hi Dirk,
Yes this is exactly as it is set up, including choosing same network as docker host as shown below, but it appears this process still doesn’t allow curl to work, the terminal process further down the guide mentions to set it --net=host.
Might be a bug in the deploy process, not setting this when deploying from the gui. I doubt would get fixed with docker for synology being deprecated, the development has now moved to container manager which is not compatible with my nas.
When I get some time this weekend I will look at a manual command line deploy and report back.
Thanks so much for all your assistance patients and the source for this.
UPDATE: I can confirm that deploying from the command line rather than using the GUI now the script is running flawlessly
i know this is an old one, but any chance for a version that does the same but for openweathermap? their API documentation is above what my head can understand
It doesn’t seem to be working for me (and by “not working” i mean that on the wunderground site, the station is showing the red icon).
This is my config: (id/key removed)
alias: WUnderground upload
description: ""
use_blueprint:
path: dvandonkelaar/wunderground_upload.yaml
input:
station_id: id
station_key: key
sensor_baro: sensor.outdoor_front_house_sensor_pressure
sensor_temp: sensor.outdoor_front_house_sensor_temperature
sensor_humidity: sensor.outdoor_front_house_sensor_humidity
refresh_frequency: 300
curl_command_service: shell_command.curl_get
trigger_entities: sensor.outdoor_front_house_sensor_temperature
I tested the curl command using the ipchecker and it did work properly.
Hi @quaka,
What is the result from the automation tracing?
And what is the result when you put the URL from the tracing in a service call for the curl_get shell command (running from Home Assistant)? I don’t know what ipchecker is and from where you run it, but it is best to run the command straight from the Home Assistant instance.