Dew point sensor

  1. Sounds good. Here is the Mosquitto broker add on configuration in 3 screenshots


Under customize (not shown in the screen shots above), I have active turned off since when it is on, I can’t connect to MQQT Explorer).

And this is the logins section. Didn’t see anything related to anonymous access other than Require Client Certificate, which is turned off.

  1. Here are the rtl_433 MQTT Auto Discovery (next) add-on → Configuration screenshots


Here is the host MQQT Explorer host info

How do I find the MQTT Explorer IP/hostname and port?

I didn’t see any rtl related errors in the Mosquitto logs (did a ctrl-F search so I wouldn’t miss anything).

One last thing. I mentioned before that I added a confg file to share/mosquitto. That at least allowed me to start mosquitto. Because of the credentials issue, I took a wild guess and put the following the config file, which I named createdbytom.conf (does the file name matter?). It didn’t change anything.
mqtt:
username: mqtt_user
password: xxxxxxx
active: true

I forgot I also have MQTT Explorer installed on my Windows machine (HA is running on an NUC). Here is a screenshot of its settings and even with the IP address as indicated, the rtl devices do not update. Maybe that is another clue.

Awesome, thanks, this is exactly the info we needed. Your Mosquitto login setup looks correct.

The key thing you’re missing is the hostname context:

core-mosquitto (and core-mosquitto.local.hass.io) only works from inside Home Assistant add-ons.
MQTT Explorer running on your Windows machine must connect to your Home Assistant IP or hostname, not core-mosquitto.

So, please do this:

  1. MQTT Explorer on Windows
    Host: 192.168.1.128 (your HA IP)
    Port: 1883
    Username: mqtt_user
    Password: the same password you set in Mosquitto
    TLS: off

  2. rtl_433 MQTT Auto Discovery (next) add-on
    This add-on runs inside HA, so it should use:
    mqtt_host: core-mosquitto
    mqtt_port: 1883
    mqtt_user: mqtt_user
    mqtt_password: same password

Save and restart the rtl_433 MQTT Auto Discovery (next) add-on.

  1. Verify in Home Assistant
    Settings → Devices & Services → MQTT → Listen to a topic
    Listen to: rtl_433/#
    You should see messages arriving again.

If it still doesn’t update, please paste lines from the Mosquitto broker log right after restarting the rtl_433 MQTT Auto Discovery (next) add-on, it will clearly show either a successful connection or “not authorised”.

Thanks. I corrected the Windows machine MQTT settings as you show in step 1. Same thing, it does not update. Step 2: those are the settings I had. Step 3: I don’t see the messages arriving.

I noticed that it is the always the same messages (sensors) and in the exact order that show up while listening in MQTT. Likewise with MQTT explorer, the values (eg temperature) are always the same. So I thought maybe there is an issue with the RTL USB radio device drivers. I removed the USB device, restarted HA and here is the MQTT log file, which contains the same error with the USB radio installed.

6-rc: info: service legacy-services successfully stopped

s6-rc: info: service legacy-cont-init: stopping

s6-rc: info: service legacy-cont-init successfully stopped

s6-rc: info: service fix-attrs: stopping

s6-rc: info: service fix-attrs successfully stopped

s6-rc: info: service s6rc-oneshot-runner: stopping

s6-rc: info: service s6rc-oneshot-runner successfully stopped

s6-rc: info: service s6rc-oneshot-runner: starting

s6-rc: info: service s6rc-oneshot-runner successfully started

s6-rc: info: service fix-attrs: starting

s6-rc: info: service fix-attrs successfully started

s6-rc: info: service legacy-cont-init: starting

s6-rc: info: service legacy-cont-init successfully started

s6-rc: info: service legacy-services: starting

s6-rc: info: service legacy-services successfully started

mqtt found in this Home Assistance instance.

Starting rtl_433_mqtt_hass.py...

[2026-02-02T08:59:16-0600] INFO:root:Discovering all devices

[2026-02-02T08:59:17-0600] INFO:root:MQTT connected: Connection Refused: not authorised.

[2026-02-02T08:59:17-0600] ERROR:root:Could not connect. Error: 5

[2026-02-02T08:59:17-0600] INFO:root:MQTT disconnected: Connection Refused: not authorised.

[2026-02-02T08:59:18-0600] INFO:root:MQTT connected: Connection Refused: not authorised.

[2026-02-02T08:59:18-0600] ERROR:root:Could not connect. Error: 5

[2026-02-02T08:59:18-0600] INFO:root:MQTT disconnected: Connection Refused: not authorised.

[2026-02-02T08:59:20-0600] INFO:root:MQTT connected: Connection Refused: not authorised.

[2026-02-02T08:59:20-0600] ERROR:root:Could not connect. Error: 5

[2026-02-02T08:59:20-0600] INFO:root:MQTT disconnected: Connection Refused: not authorised.

[2026-02-02T08:59:24-0600] INFO:root:MQTT connected: Connection Refused: not authorised.

[2026-02-02T08:59:24-0600] ERROR:root:Could not connect. Error: 5

[2026-02-02T08:59:24-0600] INFO:root:MQTT disconnected: Connection Refused: not authorised.

[2026-02-02T08:59:32-0600] INFO:root:MQTT connected: Connection Refused: not authorised.

[2026-02-02T08:59:32-0600] ERROR:root:Could not connect. Error: 5

[2026-02-02T08:59:32-0600] INFO:root:MQTT disconnected: Connection Refused: not authorised.

[2026-02-02T08:59:48-0600] INFO:root:MQTT connected: Connection Refused: not authorised.

[2026-02-02T08:59:48-0600] ERROR:root:Could not connect. Error: 5

[2026-02-02T08:59:48-0600] INFO:root:MQTT disconnected: Connection Refused: not authorised.

Because of that , I also checked some other things. Zigbee also is not working sinced the restore. Here is the Z2M log file:

          ^
Error: write after end
    at writeAfterEnd (/app/node_modules/.pnpm/[email protected]/node_modules/readable-stream/lib/_stream_writable.js:264:12)
    at File.Writable.write (/app/node_modules/.pnpm/[email protected]/node_modules/readable-stream/lib/_stream_writable.js:300:21)
    at DerivedLogger.ondata (/app/node_modules/.pnpm/[email protected]/node_modules/readable-stream/lib/_stream_readable.js:629:20)
    at DerivedLogger.emit (node:events:530:35)
    at addChunk (/app/node_modules/.pnpm/[email protected]/node_modules/readable-stream/lib/_stream_readable.js:279:12)
    at readableAddChunk (/app/node_modules/.pnpm/[email protected]/node_modules/readable-stream/lib/_stream_readable.js:262:11)
    at DerivedLogger.Readable.push (/app/node_modules/.pnpm/[email protected]/node_modules/readable-stream/lib/_stream_readable.js:228:10)
    at DerivedLogger.Transform.push (/app/node_modules/.pnpm/[email protected]/node_modules/readable-stream/lib/_stream_transform.js:132:32)
    at DerivedLogger._transform (/app/node_modules/.pnpm/[email protected]/node_modules/winston/lib/winston/logger.js:337:12)
    at DerivedLogger.Transform._read (/app/node_modules/.pnpm/[email protected]/node_modules/readable-stream/lib/_stream_transform.js:166:10)
[08:53:08] INFO: Preparing to start...
[08:53:08] INFO: Socat not enabled
[08:53:08] INFO: Starting Zigbee2MQTT...
Starting Zigbee2MQTT without watchdog.
[2026-02-02 08:53:11] info: 	z2m: Logging to console, file (filename: log.log)
[2026-02-02 08:53:11] info: 	z2m: Starting Zigbee2MQTT version 2.7.2 (commit #unknown)
[2026-02-02 08:53:11] info: 	z2m: Starting zigbee-herdsman (8.0.1)
[2026-02-02 08:53:11] info: 	zh:zstack:znp: Opening TCP socket with 192.168.1.64:6638
[2026-02-02 08:53:11] info: 	zh:zstack:znp: Socket connected
[2026-02-02 08:53:11] info: 	zh:zstack:znp: Socket ready
[2026-02-02 08:53:11] info: 	zh:zstack:znp: Writing CC2530/CC2531 skip bootloader payload
[2026-02-02 08:53:12] info: 	zh:zstack:znp: Skip bootloader for CC2652/CC1352
[2026-02-02 08:53:12] info: 	z2m: zigbee-herdsman started (resumed)
[2026-02-02 08:53:12] info: 	z2m: Coordinator firmware version: '{"meta":{"maintrel":1,"majorrel":2,"minorrel":7,"product":1,"revision":20240710,"transportrev":2},"type":"ZStack3x0"}'
[2026-02-02 08:53:12] info: 	z2m: Zigbee 2 Outlet 0xffffb40e0604f514 (0xffffb40e0604f514): 3RSP02028BZ - Third Reality Zigbee / BLE smart plug with power (Router)
[2026-02-02 08:53:12] info: 	z2m: Zigbee 1 Outlet 0xffffb40e0604b2c3 (0xffffb40e0604b2c3): 3RSP02028BZ - Third Reality Zigbee / BLE smart plug with power (Router)
[2026-02-02 08:53:12] info: 	z2m: Zigbee 3 Outlet 0xffffb40e06053eea (0xffffb40e06053eea): 3RSP02028BZ - Third Reality Zigbee / BLE smart plug with power (Router)
[2026-02-02 08:53:12] info: 	z2m: Zigbee 4 Outlet 0xffffb40e06054f47 (0xffffb40e06054f47): 3RSP02028BZ - Third Reality Zigbee / BLE smart plug with power (Router)
[2026-02-02 08:53:12] info: 	z2m: Currently 4 devices are joined.
[2026-02-02 08:53:12] info: 	z2m: Connecting to MQTT server at mqtt://core-mosquitto:1883
[2026-02-02 08:53:12] error: 	z2m: MQTT failed to connect, exiting... (Connection refused: Not authorized)
[2026-02-02 08:53:12] info: 	z2m: Stopping zigbee-herdsman...

At this point I am considering doing a fresh install of HA. It appears HA backup just doesn’t work and god knows how long it will take to resolve the rtl and now Zigbee issues. I found this post about the mosquitto share folder missing after a restore. I wonder what else doesn’t get restored.

What do you suggest? Do you think we are close? Maybe I will try reintalling all the rtl add ons and Z2M.

This is still the same root cause, and it’s not your RTL USB driver.

Both add-ons are failing with the exact same error:

  • rtl_433 MQTT Auto Discovery (next): “Connection Refused: not authorised”
  • Zigbee2MQTT: “MQTT failed to connect… (Connection refused: Not authorized)”

So Mosquitto is running, but it is rejecting the credentials used by your add-ons. Until MQTT auth is fixed, nothing that depends on MQTT will update (rtl_433, Z2M, and anything reading their topics, including Dew Point).

I do NOT think a fresh HA install is needed yet. This is very fixable.

Let’s do a clean MQTT credential reset and apply it everywhere:

STEP 1 – Create ONE known MQTT login in Mosquitto
Mosquitto broker add-on → Configuration → Logins → Add
Username: mqtt_user
Password:
Save, restart Mosquitto.

STEP 2 – Update Home Assistant MQTT integration
Settings → Devices & Services → MQTT → Configure
Host: core-mosquitto
Port: 1883
Username: mqtt_user
Password:
Save.

STEP 3 – Update Zigbee2MQTT MQTT settings (this is the big one)
In Zigbee2MQTT configuration (usually configuration.yaml in the add-on):
Set:

mqtt:
  server: mqtt://core-mosquitto:1883
  user: mqtt_user
  password: <same password>

Save and restart Zigbee2MQTT.

STEP 4 – Update rtl_433 MQTT Auto Discovery (next)
In that add-on Options:
mqtt_host: core-mosquitto
mqtt_port: 1883
mqtt_user: mqtt_user
mqtt_password:
Save and restart the add-on.

STEP 5 – Verify success in logs

  • Zigbee2MQTT log should show it connected to MQTT (no “Not authorized”)
  • rtl_433 (next) log should stop the auth loop and start publishing
  • In HA: MQTT → Listen to topic → rtl_433/# should show new messages.
  • In HA: MQTT → Listen to topic → zigbee2mqtt/# should show messages.

If you paste:

  1. Your Mosquitto “Log” right after restarting Zigbee2MQTT (10–20 lines),
  2. Your Z2M mqtt section (with password hidden),
    I can confirm it’s correct.

Reinstalling HA or restoring backups won’t help if the add-ons are still using credentials Mosquitto rejects. Let’s fix MQTT auth first, then everything else will start updating again.

I already had an mqtt_user, so I deleted that and created a new user mqtt_user2, which I also added under People. I added that user to Mosquitto and MQTT. In Zigbee configuration.yaml the user was addons and the pw was extremely long, like 50 characters. Using File editor, I changed them to the mqtt_user2 and my password. Zigbee still won’t start. It runs for a second and then stops. When it does, it also changes to user and password back to what it was. (Z2M was stopped when I made the changes so that can’t be why it reverted. I checked after I saved it and it was correct but reverted only when I tried to start Z2M)

Zigbee ran fine before the backup/restore, and my user info hadn’t changed, that’s what is so frustrating. One thing I just noticed in Z2M configuration, all of the fields in the mqtt drop down are empty. Is that right? Even though the configuation.yaml file had most of that filled in.

So nothing has changed, messages do not update. Here is the log showing the not authorized error.

I will hold off reinstalling HA (I really don’t want to anyway), but since we verified the user information is consistent across all add ons, what do you think about reinstalling the add ons? My thinking is that something got corrupted during the restore. If it seems like a logical step, which one would you try first? Either that, or there is some little switch or setting that I am missing.

This is a good clue. Two important things:

  1. Your Z2M config keys look wrong
    In your screenshot you have top-level keys like:
    mqtt_user:
    mqtt_password:

Zigbee2MQTT does NOT use those keys. It expects credentials under the mqtt: block:

mqtt:
server: mqtt://core-mosquitto:1883
user: mqtt_user2
password:

If the keys are wrong, Z2M will ignore them, connect without the right creds, and you’ll get “Not authorized”.

  1. The “reverting” behavior usually happens when config is being managed in a different place
    If you edit one file (File Editor) but the add-on UI manages another config source, your changes won’t stick or will be overwritten.

Recommended fix path:
A) In the Zigbee2MQTT add-on UI, expand the “mqtt” section and fill in:

  • server: mqtt://core-mosquitto:1883
  • user: mqtt_user2
  • password:
    Save, then restart Z2M.

OR (if you prefer file-based):
B) Edit the actual Zigbee2MQTT config file used by the add-on:
it is usually /config/zigbee2mqtt/configuration.yaml
Make sure it contains the exact block above (mqtt: → user/password), then restart the add-on.

After restart, Z2M logs should show it connected to MQTT (no “Not authorized”).

Once Z2M is fixed, apply the same idea to rtl_433 (next): it must use the exact same mqtt_user2/password as Mosquitto.

After editing, open the file again and confirm the contents are still there BEFORE starting Z2M. If it changes on start, then the add-on UI is overwriting the file and you should only configure MQTT via the add-on UI.

Okay some good news! Zigbee is working now after entering the credentials and server info in the UI. Thank you! However, rtl_433 is not updating. It is still showing unauthorized in the logs (for auto discovery). Here is the log file for rtl_433 (next)

Starting rtl_433 with rtl_433.conf...

[rtl_433] rtl_433 version 25.12-8-g8d92cdd6 branch master at 202601061318 inputs file rtl_tcp RTL-SDR SoapySDR with TLS

[rtl_433] MQTT: Publishing MQTT data to core-mosquitto port 1883

[rtl_433] MQTT: Publishing availability to MQTT topic "rtl_433/9b13b3f4-rtl433-next/availability".

[rtl_433] MQTT: Publishing device info to MQTT topic "rtl_433/9b13b3f4-rtl433-next/devices[/type][/model][/subtype][/channel][/id]".

[rtl_433] MQTT: Publishing events info to MQTT topic "rtl_433/9b13b3f4-rtl433-next/events".

[rtl_433] MQTT: Publishing states info to MQTT topic "rtl_433/9b13b3f4-rtl433-next/states".

[rtl_433] Use "-F log" if you want any messages, warnings, and errors in the console.

s6-rc: info: service legacy-services: stopping

s6-rc: info: service legacy-services successfully stopped

s6-rc: info: service legacy-cont-init: stopping

s6-rc: info: service legacy-cont-init successfully stopped

s6-rc: info: service fix-attrs: stopping

s6-rc: info: service fix-attrs successfully stopped

s6-rc: info: service s6rc-oneshot-runner: stopping

s6-rc: info: service s6rc-oneshot-runner successfully stopped

I’m wondering if this is the wrong way to enter the credentials into /homeassistant/rtl_433/rtl_433.conf.template (it is what I found on line). Without the output line, I got nothing, and found it was needed. But maybe it is calling the wrong username and password.

output mqtt://${host}:${port},user=${username},pass=${password},retain=${retain}
report_meta time:iso:usec:tz
# added next line Jan 31
#output json/
frequency 433.92M
#frequency 868.3M
#frequency 915M
#hop_interval 45
# Add other settings like specific protocols or gain here

Here is the rtl_433 Auto Discovery (next) file. Since it is an authorization problem, I verified several times that the passwords and user names match.

And for completeness, here is the log for rtl_433 Auto Discovery (next) with the same error.

More good news. I pulled the plug (literally) on the NUC running HA and rebooted. Probably not the best way to restart, but now when I listen to rtl_433/# in MQTT, it gets updated regularly. Yay! Also the authorization errors in the log file are finally gone!

I still can’t see any updates in MQTT Explorer. Maybe my settings are wrong? Also, I don’t get any messages when listening to rtl_433/433/devices/Nexus-TH-1/92/temperature_C, but I have to go back and see if we deleted that.
UPDATE: i actually can see some topics being updated, but not where I expected. Previously, they would update under the 433 subfolder, but now they appear in the area highlighted. So more good news.

I want to uninstall rtl_433 since I only use rtl_433 (next). Is it okay to delete the add-on’s data as well? Do you think that will get rid of the devices under the sub folder 433 that are not being updated?

So now I’m back to looking at the Dew Point. Remember that, lol? Here is my configuration.yaml:

# Loads default set of integrations. Do not remove.
default_config:

# Load frontend themes from the themes folder
frontend:
  themes: !include_dir_merge_named themes

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml

# The following adds a sensor to bypass the auto discovered temperature entity and create your own MQTT sensor that reads temperature_C directly and labels it as °C, then use that “fixed” sensor as the temperature source for the dew point sensor.
template:
  - sensor:
      - name: "Nexus TH Temperature Fixed"
        unique_id: nexus_th_1_92_temp_fixed_template
        device_class: temperature
        state_class: measurement
        unit_of_measurement: "°C"
        state: "{{ states('sensor.nexus_th_1_92_temperature_c') | float(0) }}"

When I go to the dew point integration and select Nexus TH Temperature Fixed, the attribute was staying at 0, even though the nexus th 1 92 temperature is being updated in MQTT (but only under the folder highlighted above, not the 433 subfolder). I noticed that the name of the nexus sensor was incorrect. It was ‘sensor.nexus_th_1_92_temperature_c’ but it should be ‘sensor.nexus_th_1_92_temperature’, i.e. without the _c at the end. Now it is updating! However, the calculated dew point is wrong. It is reporting at 98 degree dew point when the temp is 70 and the rh is 20. I tried changing units, but it is still not quite right.

Needless to say, I am so excited. I will be buying you dinner, but before I do, did you get the three coffee donation I made?

Awesome, and this explains the “98°F dew point at 70°F / 20% RH” issue.

I’ve pushed an update that fully supports °F input + configurable output units.

How it works:

  • The integration reads the temperature value + its unit.
  • If the input sensor is °F, it converts to °C internally before calculating dew point (so the math is correct).
  • With output unit = Auto, the dew point is reported in the same unit as the input sensor (°F in your case). You can also force °C or °F in the config UI.

What I suggest you do now:

  1. Update the Dew Point integration to the latest version.
  2. In the Dew Point config, select your real temperature sensor (the one that shows 70.xx °F), no template conversion needed.
  3. Set output unit to Auto (or choose °F explicitly).
  4. Remove/disable the “Nexus TH Temperature Fixed” template sensor afterwards if you don’t need it anymore.

With 70°F and 20% RH, a reasonable dew point is around ~24°F (≈ -4°C), not ~98°F. After the update you should be in that range.

Yes I got the coffees, Thanks a lot, I really appreciate it.

Wow, that was fast! I am having trouble updating the integration, though. I followed the instructions on Github using HACS, but the interface looks the same, even after a restat. I don’t see any option to set units to auto. Also, the calculation isn’t deriving the correct dew point. However, if I set C as the units, then it reports a dew point of 15C. That value would be about right if it was in F.

The termperature attribute is also wrong. The sensor display shows 64F, and MQTT Explorer also shows it at 64, but the integration thinks it is 15.5F. That would be almost correct if it were in C but it should be more like 17.7. I have set it to use the actual sensor data, not the template. The humidity seems reasonable at 99 as that is what the sensor’s display is reporting.

Finally, any suggestions on deleting rtl_433 and the add on’s data since I don’t use it?

Go to the setting - devices and the Dew Point, make sure you are on the right version

One more thing based on your latest screenshot.

Right now the main problem is not the dew point formula, it’s that the integration is reading the wrong temperature value:
Your sensor display shows ~64°F, but Dew Point attributes show 15.5°F.
So the Dew Point config is either pointing to the wrong temperature entity, or the selected entity has a different “native” unit/value than what the UI is displaying.

Can you paste these two items (copy as text from Developer Tools → States):

  1. The exact entity_id you selected as temperature_sensor in the Dew Point config.
  2. The full state + attributes for that entity (especially unit_of_measurement, state_class, device_class, and any “temperature”/“native_value” fields if present).

Quick check:
In Developer Tools → States, does that temperature entity’s STATE show 64, or does it show ~15.5?
If it shows ~15.5, then it’s actually reporting in °C (15.5°C ≈ 60°F) or it’s a different sensor than you think.
If it shows 64, but Dew Point reads 15.5, then we’re not actually using the entity you think, or there’s an entity registry duplicate.

Also, “Auto” output unit only appears in the latest integration version and only inside the config entry settings (gear icon) as in my screenshot. If you don’t see it, please confirm the integration version shown on Settings → Devices & Services → Dew Point.

Regarding removing the old rtl_433 add-on:
Yes, you can uninstall rtl_433 if you only use rtl_433 (next). Deleting its add-on data is fine. Old MQTT topics under rtl_433/433 can remain if they were retained. If you want them gone, clear retained messages for those topics in MQTT Explorer (or temporarily disable retain and restart the publishing add-on).

My bad. I am still using V 0.4 and I see that the latest on Github is 0.6. But I’m still stuck on how to update. I go to HACS, clcik 3 dots, custom repostitories, paste the url GitHub - Nicxe/Home-Assistant-Dew-Point: A sensor for dew point in Home Assistant and click add. Then I click on add configuration button on the github page

When I go to integrations, there is the Dew Point with 3 entities now, but the version shows still 0.4.

Sorry for being such a dunce. Once I get the latest version, I’ll continue with the diagnosis.

Two options, update information and HACS will understand there is a new version

Or manually download it

The first option didn’t work. Updated information but still shows V0.4, even after a restart. Then it disappeared after restart, so I added it again to custom repositories. But redownload worked like a charm and as soon as I entered the sensor data, it gave me the dew point as expected and I didn’t have to change anything. If you want to see any of my screens, let me know. BTW, I left output units set to ‘auto’.

Dinner is on me tonight, donation sent! Thank you, sir!

That’s awesome, really glad you got it working in the end, and thanks for sticking with the troubleshooting.

Your case was super useful feedback and helped validate the °F input + Auto output flow, so others won’t hit the same confusion.

Thanks a lot for the coffee as well, I really appreciate it.