#MQTT device IP address reconfiguration

1 messages · Page 1 of 1 (latest)

static veldt
#

I tried various ways to re-add an MQTT device that had been tested "on the desk" and as it was connected to the wrong router port it landed in the wrong network.
So, after I finished configuration, I thought I just enter the correct IP and plug it into the right port...
But I failed:
There is no IP address to be modified in the menu. I also cannot find it in the .storage/core.config_entries
When I send a new HA Discover, the ID is received, then HA eats up some more memory, gets unresponsive and takes 5 minutes to recover.
What can I do next?

static veldt
#

Okay, the MQTT device is in the core.config_entries but only with an ID, not any kind of IP address. So I simply deleted the device and made the thing send a new discovery. As a result HA starts to pull immense amounts of RAM and disconnects. After 3...4 minutes it now responds again, but increased memory consumption from 3.3GB to 6.7GB

#

Ayn time I return to the MQTT Devices page, HA gets unreponsive again.

static veldt
#

I removed the device manually from several core.* files but it is still not possible to add it. However, when I try to add it, even it fails in the end, core.device_registry is again modified and the device is added. But it still doesn't show up in the MQTT devices list

static veldt
#

Okay, it is still in the home-assistant_v2.db and I hve no idea of how to get it out of there

static veldt
#

Nobody any idea?

mighty minnow
static veldt
#

I assign the IPs via DHCP but fixed for each device. So yes, the router assigns the same IP to every device in that IoT network. But when playing with the device it was on a switch that assigned it dynamic and into my computer network. Port was not in the IoT VLAN

static veldt
#

The supervisor log shows a login from the MQTT device
2025-08-13 12:39:09.558 INFO (MainThread) [supervisor.auth] Auth request from 'core_mosquitto' for 'MQTT'
2025-08-13 12:39:09.858 INFO (MainThread) [supervisor.auth] Successful login for 'MQTT'

#

But then something fails:
2025-08-13 11:27:00.990 ERROR (MainThread) [firebase_messaging.fcmpushclient] Unexpected exception during read
Traceback (most recent call last):
File "/usr/local/lib/python3.13/site-packages/firebase_messaging/fcmpushclient.py", line 687, in _listen
elif msg := await self._receive_msg():
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/site-packages/firebase_messaging/fcmpushclient.py", line 300, in _receive_msg
r = await self.reader.readexactly(1) # type: ignore[union-attr]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/asyncio/streams.py", line 769, in readexactly
await self._wait_for_data('readexactly')
File "/usr/local/lib/python3.13/asyncio/streams.py", line 539, in _wait_for_data
await self._waiter
File "/usr/local/lib/python3.13/asyncio/selector_events.py", line 980, in _read_ready__get_buffer
nbytes = self._sock.recv_into(buf)
ConnectionResetError: [Errno 104] Connection reset by peer
2025-08-13 12:13:54.203 ERROR (MainThread) [custom_components.bestway.coordinator] Timeout fetching Bestway API data

static latch
#

Those timestamps indicate you are skipping log entries and perhaps blaming MQTT for issues happening elsewhere. I'd start by first looking at this error:

2025-08-13 12:13:54.203 ERROR (MainThread) [custom_components.bestway.coordinator] Timeout fetching Bestway API data

This is most likely a network outage or an issue with DNS

static veldt
#

Acrtually, if you read carefully, you can see, that the first two lines are from the supervisor log and the second snippet is from the core log. So you are blaming me for something I didn't do. I am also not blaming anyone for anything, I just have no clue why it is not working and hope that someone point me to the problem, that either may be in the HA system or sitting on fron of my PC.

#

The bestway problem is introduced by HAOS as the new system seems to insist of devices providing a UID and the bestway API implementation is not providing any. So it is to be expected that there is an error. Unfortunately I wasn't aware of that to happen, so the pool control that I implemented last week is now gone.

#

In the current state the system is, it is enough to click "Add New Device" in MQTT and close the configuration window again. That makes HA unresponsive but does not create any log entries. So yes, the lines above may be caused by an outdated Bestway API and are unrelated to the MQTT issue, but they where the only log entries I got.

#

Okay, progress. I pulled the whole logs from the system and found that it initally claims a duplicate Bestway installation or device. I found that the original Bestway Spa was empty without controls and a second spa was added with all settings available and working. So I deleted the empty one. After deletion of the empty spa, HA went unresponsive again for about 2 minutes. Now as it is back it only argues about one DNS entry not working with bestway, but obviously that isn't really needed as it works perfectly controlling the little spa.

#

I am investigating "usapi.gizwits.com" and why it is not reachable. I have lots of blocks set to eastern Europe and China but that should be a US server that is not recognized by 1.1.1.1 or 8.8.8.8 DNS services.

#

Interesting!
pinging this service in HA VM console does not work, pinging it on the host system works perfectly. How can that be?
Looks like I am not the only one with an internet connection issue since one of the last HAOS updates.
https://community.home-assistant.io/t/integrations-cant-reach-internet-since-2025-3-3/864828

Home Assistant Community
Integrations can't reach internet since 2025.3.3

since I upgraded to 2025.3.3 network (internet) comms for integrations fail after some runtime. 2025-03-16 23:22:47.405 ERROR (MainThread) [homeassistant.components.flux_led.coordinator] Error fetching 192.168.0.214 data: [Errno 113] Connect call failed ('192.168.0.214', 5577) 2025-03-17 00:29:33.525 ERROR (MainThread) [homeassistant.components...

static latch
#

So, you get someone trying to help and then tell them they have to look carefully. Instead, why don't you learn to format your messages correctly to make things clearer.

I saw the 'But then something fails:' text, then saw that the first entry is 1 hour earlier then the Supervisor log entries. So, it is not 'but then something else fails' as that failure already happened.

As for your MQTT issue - which I didn't even address - you should take some time to learn about it. MQTT is a message transfer system and as such Home Assistant and the various devices use specific topics to send payloads. Therefore, there is no need for an IP Address in the 'core_config_entries'for the device.

You have also edited a system file (core.config_entries) manually, which should only be done when you truly know what you are doing which clearly you do not.

static veldt
#

As I wrote above, I am tracking it down while I am learning how things connect in HA. I backed up the system files before making changes.

#

I also pinged the usapi system from HAOS where its name is not resolved, but I can ping it without any problems from the Proxmox system hosting the HAOS VM

#

So even the aws doesn't reply to pings, HAOS cannot resolve the name and Proxmox as a host can.

#

This may be completely independant from the MQTT problemn or the MQTT problemn may be related to it. But as you already wrote initially, lets resolve the basic issues first.

#

I also did not change any configuration on the Proxmox host or in the VM configuration. I just updated HAOS to th latest revision.

static veldt
#

Okay, for me it looks like my initial network setup was not helping too much. I am using multiple networks / VLANs to divide infrastructure from user and guest areas and I also run a DMZ where the exposed services are located. With the help of a friend we walked through the whole installation and found one not so clever decision was made to put the HA to the DMZ instead of forwarding two ports to the internal network. Second there was a mis-config on one port of a switch that isolated the infrastructure network from HA.

#

The first trial of sending a discovery from the dingtian 4-channel MQTT unit just again resulted in a 3 minute silent reboot of HA but after that the unit just was recognized and is working since then.

#

Still there is a mystery why certain DNS discoveries are not possible inside HA while the VM can access the router and everything. But that will be traced out tomorrow.

static latch
#

Do you use a separate VLAN for IOT? Do your user / guest VLAN's cater for WiFi and if so are you using AP's that support multiple VLAN's or do you have AP's connected to switch ports in the relevant VLAN.\

#

Is your mqtt server in the DMZ or in a VLAN?

#

In the Home Assistant UI go to Settings -> System -> Network and see what you have for DNS Servers under IP4 and IP6

static veldt
#

I am using VLAN for almost everything. However in generar there is the inner world and the outer worls. And for a service that only represents a "page" to the outworld but has lots of tasks in the inner world, it is more practical to put the VM into the inner world and just forward the two ports via proxymanager. The DNS servers are set correctly, the HA VM is in the IoT VLAN. Interestingly the DNS settings are correct, but don't work. Currently we have guests and I am only able to check for details tomorrow in the early evening.

#

Just did a quick check. The DNS server is set correctly, the same as for all other devices in that domain. But I'll check the settings on the UDM Pro tomorrow.

static latch
#

Do you have any firewall rules on the UDM Pro?

static veldt
#

Hi @static latch !
Yes sure! But scrolling through the logs and testing a bit, there is only that Bestway thing left open. All the other faults could be resolved by myself.
The Bestway spa wants to connect to usapi.gizwits.com:443 and fails. Testing a wcurl to that address gives an error 404 what looks like it is at least doing the DNS resolveing correctly. Unfortunately there are no network tools on that VM.

#

But there is another host that cannot be reached, so I assume another issue with DNS, ICMP permissions or something else I cannot see at the moment. I need to figure out how to install some basich network test tools to the VM.

#

I tested from the DMZ to these servers and DNS works but these server block ICMP.

#

As all other machines on the same subnet of the HAOS VM are able to resolve any DNS names using the same UDM Pro as DNS forwarder, I think I need to find out what is different on that VM.

static latch
#

on the Home assistant server at the CLI check what 'ha network info' shows

static veldt
#

The output is perfectly fine and corresponds to my PC or other devices on the same subnet. Same subnet, same DNS

static latch
#

One way to see if your firewall is blocking is to create a new rule that runs before all other rules and allows all traffic from behind it out the WAN. Alternatively just disable the firewall whilst you run a quick test.

static veldt
#

There is no blocking rule on that subnet.

#

Other machines on the subnet can access the links perfectly

static latch
#

What are you using for virtualization? Proxmox or something else?

static veldt
#

Proxmox

#

Firewall on Proxmox is off on that VM

static latch
#

I would suggest you spin up a new VM on the same subnet using a Kali Linux - that will give you networking tools

static veldt
#

Okay, again:
The HA VM and the PC I am just typing with are both in the same subnet. And my PC can reach these sites. I can call them in the browser and get a "ERR_EMPTY_RESPONSE" for the usapi.

#

Anyways, Kali is coming in

#

I'll install it as a VM, like HA and I will connect it to the exact same subnet where the HA VM resides. So they share the same infrastructure

static latch
#

Yes

#

However, I'm wondering why you don't just consider taking a copy of your config directory in HA, then shutting down the HA VM and create a new one from scratch and copy the config .

static veldt
#

?

#

That would probably not solve anything? As the settings in question would be copied over?

static latch
#

Which settings? Most of the Network settings which is what you appear to be having an issue with are done at the Host OS level and not in the config folder.

static veldt
#

Good to know.

#

Is it just needed to copy away the config directory and everything re-appears in a new instance?

static latch
#

It should do - you need to make sure you copy any '.' folders such as .storage

static veldt
#

Interestingly nslookup on HAOS can find the servers. And the Bestway API can be called. The error messages seem not to hinder the device to work.

#

And I'll go upstairs and reboot the Somfy / Tahoma box as it did not update DHCP information.

molten schooner
#

ping and nslookup resolve names differently. One working and the other one not is not uncommon. Also as SJ pointed out earlier the MQTT server doesn't care about it's address. All it cares about is the address it needs to forward messages to. When we ask you to try something, please don't tell us why it's not the issue, just try it so we can continue through our thought process debugging it.

static veldt
#

Yes and no. I try to get things working on one hand and to understand on the other. And on the third Hand I try to fix my issues. And being asked to "ah just copy some directories out of it and then scrap the whole thing" is not something I want to do in the middle of the week, having had a 10h day shipping around riffs placed by Xilinx / AMD in their ZynqMP sources.

#

While being pretty firm with all bare metal and Kernel and such, I am not so good in VM and how to copy things in and out of these. I need to check where thins are put best. And yes, I know I can just create a new VM with a current version of a current Proxmox script, but then I have to get the tar.gz of my backup back into it.

#

I am the guy you call, when your mainboard features a new chip and there is no driver for it. Plainly said, I am working on the opposite end of the computer, from the view of a VM

static latch
# static veldt I am the guy you call, when your mainboard features a new chip and there is no d...

This statement is a contradiction in itself. If a mainboard features a new chip and we call you because there is no driver are you writing the driver? A VM is somewhat similar to a mainboard in the sense that you install an OS which has a kernel supporting the features exposed by the VM.

It's been 9 days since my first post trying to assist. I have noted that you never seem to respond to any questions directly and hence it makes it difficult to assist since we are jumping from one place to another.

You have stated:

"I removed the device manually from several core.* files but it is still not possible to add it"
"Okay, it is still in the home-assistant_v2.db and I hve no idea of how to get it out of there"

These are system files, and whilst it is possible to edit these you really need to know what you are doing and how they will effect the software.

You then say:

"pinging this service in HA VM console does not work, pinging it on the host system works perfectly."

Well, that indicates that ICMP is being blocked between the Host and VM. However, I get stumped because I know Amazon would be blocking the pings so don't know how you are getting a response.

We then get:

"Okay, let's restart. If I check the messages, HAOS cannot resolve the name. If I use Proxmox console to resolve the name, I get this:
ping usapi.gizwits.com
PING usopenapi-pub-elb-939734508.us-east-1.elb.amazonaws.com (3.215.59.20) 56(84) bytes of data.
NEW
[10:06]
So even the aws doesn't reply to pings, HAOS cannot resolve the name and Proxmox as a host can."

Well, that makes more sense to me as Amazon does block the pings - so what were you pinging earlier? Your statement earlier had me going down a different rabbit hole. Now I start to think ok, its a DNS issue (as most IT guys say it is always a DNS issue).

#

You then say your initial network setup was not helping much. Using multiple networks and VLANS - you haven't posted a single detail on VLAN ID's or Internal IP addressing and routing. So we are supposed to guess.

I asked: on the Home assistant server at the CLI check what 'ha network info' shows
You respond: The output is perfectly fine and corresponds to my PC or other devices on the same subnet. Same subnet, same DNS

I think ok, he knows so good. However, having gone back I think wait did he set a static ip for something and then put it in the wrong VLAN so its not actually in the correct subnet? Without you posting some details of your set-up it's going to be impossible.

The fact is in the 15 days since your first post, you probably could have started a new HA server and rebuilt the configuration. You actually would have saved time not just yours but mine as well.

So yes, this message is critical but hopefully you will understand why I may not provide further assistance to you.

static veldt
#

Sorry, but I have to do too many things at once currently. We had planned for doing some isolation works and the workers should have started two weeks ago. But they found the woodworm in the ceiling. So we have to re-plan completely. In addition I have to re-build my lab but the walls that need to be remove where made in the 1950 or earlier with a mixture of concrete that survives a massive bombardment. I partly coordinate all that work and re-planning, have 9..10h work day and do dome of the renovaitons myself.

#

The woodworm problem came in when I was analyzing the HA network thing. We could discuss how much different low level programming in C99 and Assembler is, compared to highlevel works with file services getting things inn and out of VMs. I can do that, but as stated before, I need to concentrate on other things first. And as HA was 90% working and does now work almost 98% after fixing the VLAN and DHCP setting, only a few temporary appearing error messages are left. I have a lot of stuff I like to add to my HA setup, but I need to postpone that until I get the major issued solved.

#

But to not keep people hanging in the air, by saying "it works" but not telling how, here some short findings and results:
I have 4 networks. A DMZ, a computer network, a IoT network and a guest network. As the HA is reachable over the internet for remote monitoring and control through the app, I had the server sitting in the DMZ. Bad idea!
But, even the IoT and Computer network have more or less full outbound rights, they only have "matching return" input permissions. For starters that means, that devices may create an outbound connection, and the called system may respond, but no system is allowed to call an internal device directly.

#

That lead to a trap. When the MQTT device sent a HA resolver package it was received by HA. But then HJA wants to read the configuration from the device and that was rejected by the firewall.

#

The solution was to put the HA server into the IoT network and set two forwarding rules from the DMZ to the HA server that poke the usual holes and allow access to the server. This also requires to modify the settings of nginx proxymanager, as usual.

#

Finally, when rushing through the settings, I had the silly idea to apply fixed addresses to some devices in the device and set the DHCP range such that it spares out some addresses for that. But instead of changing the DHCP address range, I changed the interface address of the router of that VLAN. Probably just too late at night, when I did that. So after that mistake, all units with a fixed IP settings tried to contact the DNS server on the old address and therfefore failed.

#

Yes, if there weren't these sudden events when you renovate a 100 year old farm, I would have moved the old config to the new VM I already built. I really appreciate the support in this forum. A lot of questions could be solved, some not. This one is on me, I didn't plan that woodwom thing. Got me and I now have to deal with it. Will just double the cost and upgrade from a thermal isolation to a full blown renovation.

#

And here are the network settings:

ha network info

docker:
address: 172.30.32.0/23
dns: 172.30.32.3
gateway: 172.30.32.1
interface: hassio
host_internet: true
interfaces:

  • connected: true
    enabled: true
    interface: enp6s19
    ipv4:
    address:
    • 192.168.10.50/24
      gateway: 192.168.10.1
      method: static
      nameservers:
    • 192.168.10.1
      ready: true
      ipv6:
      addr_gen_mode: default
      address:
    • fe80::3ffc:xxxx:xxxx/64
      gateway: null
      ip6_privacy: default
      method: disabled
      nameservers: []
      ready: true
      mac: XX:XX:11:XX:00:XX
      primary: true
      type: ethernet
      vlan: null
      wifi: null
      supervisor_internet: true
#

But an nslookup works fine.

#

For this escalating topic, the MQTT problem is completely solved. The bestway issue is open. For the peace of all our minds, and to stay friends, I would suggest that I postpone the investigation of the bestway DNS issue until I can dig into it and reply to your requests in short times. And the bestway pool is working completely fine and can be controlled by HA. I wonder if that bestway cloud access is even needed. But before I pull Wireshark and check that package content. I need to clean a lot of work.

static latch
#

Sorry to hear about the Woodworm.

So, the main issue was that you accidentally messed up the DHCP settings.

Given that you have a DMZ, LAN, IOT and Guest - this is what I would do:

1). DMZ - All public services (Nginx Proxy Manager)
2). LAN - As usual
3). IOT - Everything to do with home automation (HA, MQTT, InfluxDb etc. as well as all devices)
4). Guest

Then you just need inbound rules for DMZ only.

Additionally settings for:
DMZ nginx proxy to HA Server
LAN PC to All (main PC you use - allowing management of anything)
mDNS from LAN to IOT (allows Chromecast from mobile to TV etc.)

Optional:
DHCP used for all devices on IOT with IP reservations for permanent devices
Create groups for devices - Allowed Internet and Blocked and create firewall rules accordingly.

#

As for the bestway issue, one of the errors was 'timeout' which indicates HA couldn't contact the Bestway servers. This may not be something you can rectify as they may have had an outage / being doing updates or even rate limiting access to their API.

static veldt
#

I set it up exactly like you mentioned. The HA is currently in LAN, but LAN only has some more filters regarding ad-blocking compared to IoT. But the networks IoT and LAN have full cross access.

#

DHCP Yes: All devices are back on DHCP and the DHCP assings fixed addresses from his database.

#

2025-08-24 10:28:45.681 ERROR (MainThread) [custom_components.bestway.coordinator] Error requesting Bestway API data: 502, message='Bad Gateway', url='https://usapi.gizwits.com/app/bindings'
2025-08-24 13:44:24.955 ERROR (MainThread) [custom_components.bestway.coordinator] Timeout fetching Bestway API data
2025-08-24 14:40:55.956 ERROR (MainThread) [custom_components.bestway.coordinator] Timeout fetching Bestway API data
2025-08-24 15:10:55.383 ERROR (MainThread) [custom_components.bestway.coordinator] Error requesting Bestway API data: 502, message='Bad Gateway', url='https://usapi.gizwits.com/app/devdata/L8gALRbRcHYukHA5FLsiB0/latest'
2025-08-24 17:37:59.155 ERROR (MainThread) [custom_components.bestway.coordinator] Error requesting Bestway API data: Cannot connect to host usapi.gizwits.com:443 ssl:default [Timeout while contacting DNS servers]

These are the last messages from the bestway issue. Looks like it fails every now and then. We might want to consider, that my spa is sort of an early model. And it also requires to use the early app. So chances are high, that this thing relies on an eraly api...

#

Luckly the water filters are available from various sources and in case they cease the App support one day, I'll throw their control unit out and put mine in.

static latch
#

This is the reason I check what integrations are available before purchasing any hardware. I don't want to use cloud polling because I feel a lot of manufacturers do not understand the implications. They all jump on the let's have a mobile app / internet control bandwagon but don't consider on-going costs. As they sell more devices there hosting costs for API's increase but this hasn't been factored into the price of the hardware.

I don't think you will be able to do anything about the Bestway errors - although you should check issues on the Github Repo and perhaps create an issue if you feel yours is not covered.