all entities with a value template in their yaml definition became 'unknown'?

[ArjenR49]

all entities with a value template have become unknown a few days ago, perhaps after an update. That is all except RPI Power and fanspeed. Fanspeed is updated normally, i.e. instantly, but all else has remained unknown for several days now despite all my attempts to solve the problem, which I figured was caused by the deprecation of MQTT settings and the changes I applied to circumvent that.

I changed the name of the location around that time, too, but I don't think that caused the problem.

One thing which may be connected to it, I thought, is the fact that several MQTT settings have become deprecated and eventually I commented all lines of the mqtt definition block in configuration.yaml, and Re-configured MQTT with the appropriate settings in the UI of HA.

I did not change the mqtt block in fanShutDownUps.ini:

[mqtt]
# leave BROKER blank to disable MQTT
BROKER=192.168.1.xx
TCP_PORT = 1883
# leave USERNAME blank if no login is required
USERNAME = myname
PASSWORD = mypassword
TOPIC = home/rpi

My HA setup had been working fine since last november at least before this sudden problem. Everything involved is on one and the same Pi4 running Bullseye, UPSplus, HA, Mosquitto and of course a lot more. It has an SSD for its storage medium.

I have seen reports of similar problems, but they occurred many versions ago. I have always updated HA and Mosquitto whenever there was an update available. I have listened to home/rpi/# and there, too, all I get is the fanspeed and some messages about being online etc. The fact that the fanspeed shows up normally, should tell a whole lot, I expect, as it comes from the python program fanShutDownUps.

My understanding of this whole HA and Mosquitto business is very poor. I can apply things I see being done somewhere, but that's all. Also the OO code of the python control program is way over my head. Again, based of examples I can make small changes.

Any idea as to where to look for a solution? Or should I perhaps just wait for an update to fix this?

[frtz13]

do you get any messages from fanShutdownUPS in the system log of the RPi? normally you should get an error about "reading UPS registers..." every hour or so. maybe something is wrong with the i2c bus on your system?

[ArjenR49]

Below are some error messages from the syslog of today.

Just a minute ago I stopped and disabled motioneye, as it seems to be filling the log with messages. (I hadn't noticed that before, although I knew that motioneye doesn't play well on Bullseye with the RPi camera, but that's a different subject.)

The message about no attribute '_current_lsb': I seems to remember that it has always been present and perhaps even discussed here. It is odd in a sense that it seems to be a problem with the INA219 object and library ... I update the OS very regularly.

My own reporting script works fine, so apparently that error is inconsequential. I assume the errors in between are to do with motioneye. I have not yet restarted the Pi since disabling motioneye.

Edit: My assumption was wrong. After rebooting the same error messages '[INFO] 127.0.0.1:50779 - 45380 "NS IN . udp 17 false 512"' and 'connection refused' came up, but with 635 instead of 766 as in the excerpt below. I think it is the process id. Process 635 is something with docker in the name and now I am really out of my depth :-(

May 11 11:30:12 RPI-HUB fanShutDownUps.py: [get_UPS_status_and_check_battery_voltage] Error getting data from UPS: [UPSPLus.init] Error reading inaBatt registers: 'INA219' object has no attribute '_current_lsb'
May 11 11:30:12 RPI-HUB 3d4df8b2af64[766]: [INFO] 127.0.0.1:50779 - 45380 "NS IN . udp 17 false 512" NOERROR - 0 5.000775584s
May 11 11:30:12 RPI-HUB 3d4df8b2af64[766]: [ERROR] plugin/errors: 2 . NS: dial tcp 1.1.1.1:853: connect: connection refused
May 11 11:30:13 RPI-HUB fanShutDownUps.py: [C_UpsCurrent.add_value] Error reading inaBatt registers: 'INA219' object has no attribute '_current_lsb'

This is error messages I get from fanshutdownups in the syslog. At intervals of a minute or so. Not hours. The UPS's battery evaluation interval (blue leds off) is set to 10 minutes.

From the beginning of this syslog I found this [Errno 121] message, which is common and we have discussed it before at length. It is infrequent, at intervals of about half an hour. On May 8th, the unknown values problem with HA had not started yet. Indeed on that day, the only error messages from fanshutdownups were the Errno 121 messages.

I have since tried some extra parameters to INA219 commands as you can see below. I have made the same changes to my own python report script (which just runs ans reports to the terminal) and they cause no problems. I have tried various alternatives as you will notice from the code snippet below.

    # Battery current and voltage
    try:
#        inaBattery = INA219(0.005, busnum=DEVICE_BUS, address=0x45)
#        inaBattery = INA219(0.011, busnum=DEVICE_BUS, address=0x45)
        inaBattery = INA219(0.011, 4, busnum=DEVICE_BUS, address=0x45)
##        inaRPi.configure()
        inaRPi.configure(inaRPi.RANGE_16V, inaRPi.GAIN_2_80MV, inaRPi.ADC_32SAMP, inaRPi.ADC_32SAMP)
##        inaRPi.configure(inaRPi.RANGE_16V)

(I notice I need to change the syslog rotation plan. I only learned how to do that a week or so ago, but until now I have only applied it to my PiHole server, which has an SD card and zRAM ...)

May  8 00:31:55 RPI-HUB fanShutDownUps.py: [get_UPS_status_and_check_battery_voltage] Error getting data from UPS: [UPSPLus.init] Error reading UPS registers:May  8 00:31:55 RPI-HUB fanShutDownUps.py: [get_UPS_status_and_check_battery_voltage] Error getting data from UPS: [UPSPLus.init] Error reading UPS registers: [Errno 121] Gindse invoer-/uitvoerfout

Fanshutdownups.ini:

[fan]
# GPIO pin for fan speed control
# set to -1 to disable fan control
# set to 18 for hardware(?) PWM on pin #12 
GPIO_FAN = 18
# fan speed will be calculated and set with this frequency
FAN_LOOP_TIME_s = 5
# fan will start at this temperature
# Will be read anew at every fan speed evaluation loop
#DESIRED_CPU_TEMP_degC = 25 # defeats fan speed control making fan run at 100% duty cycle
DESIRED_CPU_TEMP_degC = 47

[ups]
# uncomment the following 2 lines for testing (= shut down without first running down the batteries).
TIMER_BIAS_AT_STARTUP = 0
##SHUTDOWN_IMMEDIATELY_WHEN_ON_BATTERY = 1
#
# send UPS status. set to 1 to send. Otherwise set to 0.
SEND_STATUS_TO_UPSPLUS_IOT_PLATFORM = 1
UPSPLUS_IOT_PLATFORM_URL = https://api.52pi.com/feed
# loop frequency for battery status check. status will also be sent via MQTT with this frequency
BATTERY_CHECK_LOOP_TIME_s = 60
# ups will shut down RPi the power supply with this delay after OS shut down command was given
SHUTDOWN_TIMEOUT_s = 60
# supported values are between 100 and 500. Recommended value: 200
PROTECTION_VOLTAGE_MARGIN_mV = 200

[mqtt]
# leave BROKER blank to disable MQTT
BROKER=192.168.1.***
##BROKER =
TCP_PORT = 1883
# leave USERNAME blank if no login is required
USERNAME = ****
PASSWORD = ****************
##USERNAME =
##PASSWORD =
TOPIC = home/rpi

In HA Gui Re-configuring MQTT causes no errors and the HA log also says there are no problems.

Listening to # only produces messages like these:

Bericht 3 ontvangen op home/rpi/fanspeed om 11:46:
0
QoS: 0 - Retain: false
Bericht 2 ontvangen op home/rpi/fanspeed om 11:46:
55
QoS: 0 - Retain: false
Bericht 1 ontvangen op home/rpi/fanspeed om 11:46:
64
QoS: 0 - Retain: true

I have made no changes to and not touched the hardware since last year and the pi and HA have worked fine since that time. It is just motioneye that doesn't play well as far as the local camera is concerned. The brightness is uncontrollable. Something to do with changes to Bullseye.

I hope this is useful information to go by. Thanks a lot for your efforts in making the UPSplus into a useful thing. I could never have done that Python code myself.

[ArjenR49]

The errors apparently related to docker started on May 3d. In older logs since november 2021 they are not present. They are filling the syslog ...

May  5 22:43:02 RPI-HUB 3f6b8e4055d9[782]: [INFO] 127.0.0.1:52822 - 10479 "NS IN . udp 17 false 512" NOERROR - 0 5.001183322s
May  5 22:43:02 RPI-HUB 3f6b8e4055d9[782]: [ERROR] plugin/errors: 2 . NS: dial tcp 1.1.1.1:853: connect: connection refused
May  5 22:43:04 RPI-HUB 3f6b8e4055d9[782]: [INFO] 127.0.0.1:41367 - 58740 "NS IN . udp 17 false 512" NOERROR - 0 5.000925094s
May  5 22:43:04 RPI-HUB 3f6b8e4055d9[782]: [ERROR] plugin/errors: 2 . NS: dial tcp 1.1.1.1:853: connect: connection refused
May  5 22:43:05 RPI-HUB 3f6b8e4055d9[782]: [INFO] 127.0.0.1:49825 - 38711 "NS IN . udp 17 false 512" NOERROR - 0 5.000959399s
May  5 22:43:05 RPI-HUB 3f6b8e4055d9[782]: [ERROR] plugin/errors: 2 . NS: dial tcp 1.1.1.1:853: connect: connection refused

Currently fanshutdownups errors are only the ones with ''INA219' object has no attribute '_current_lsb''

[frtz13]

lets try this: please stop the script in the background: pkill -f fanShutDownUps.py re-start the script: python3 fanShutDownUps.py --notimerbias and look for messages (console messages, system log)

[ArjenR49]

Console messages:

`pi@RPI-HUB:~/UPSPlus_MQTT $ python3 fanShutDownUps.py --notimerbias UPS-Plus to MQTT version 20220110 Copyright (C) 2021 https://github.com/frtz13 This program comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under conditions of the GPL (see http://www.gnu.org/licenses for details).

Timer bias at start-up set to 0 Type ctrl-C to exit Connecting to broker 192.168.1.51 [get_UPS_status_and_check_battery_voltage] Error getting data from UPS: [UPSPLus.init] Error reading inaBatt registers: 'INA219' object has no attribute '_current_lsb' [get_UPS_status_and_check_battery_voltage] Error getting data from UPS: [UPSPLus.init] Error reading inaBatt registers: 'INA219' object has no attribute '_current_lsb' [get_UPS_status_and_check_battery_voltage] Error getting data from UPS: [UPSPLus.init] Error reading inaBatt registers: 'INA219' object has no attribute '_current_lsb' [get_UPS_status_and_check_battery_voltage] Error getting data from UPS: [UPSPLus.init] Error reading inaBatt registers: 'INA219' object has no attribute '_current_lsb' .... ` Nothing else in the console.

I seem to remember that this message has always been there, but not sure and I don't understand why there would be such an attribute missing from the object. As I understand it, the object is from library code, so how would that have gone unnoticed by the makers of that code.

syslog:

....

May 11 17:20:47 RPI-HUB ee272bca20e3[680]: [ERROR] plugin/errors: 2 . NS: dial tcp 1.1.1.1:853: connect: connection refused
May 11 17:20:49 RPI-HUB ee272bca20e3[680]: [INFO] 127.0.0.1:52956 - 60015 "NS IN . udp 17 false 512" NOERROR - 0 5.000337129s
May 11 17:20:49 RPI-HUB ee272bca20e3[680]: [ERROR] plugin/errors: 2 . NS: dial tcp 1.0.0.1:853: connect: connection refused
May 11 17:20:50 RPI-HUB ee272bca20e3[680]: [INFO] 127.0.0.1:51849 - 53447 "NS IN . udp 17 false 512" NOERROR - 0 5.000646069s
May 11 17:20:50 RPI-HUB ee272bca20e3[680]: [ERROR] plugin/errors: 2 . NS: dial tcp 1.0.0.1:853: connect: connection refused
May 11 17:20:51 RPI-HUB fanShutDownUps.py: [get_UPS_status_and_check_battery_voltage] Error getting data from UPS: [UPSPLus.init] Error reading inaBatt registers: 'INA219' object has no attribute '_current_lsb'
May 11 17:20:52 RPI-HUB ee272bca20e3[680]: [INFO] 127.0.0.1:53523 - 57213 "NS IN . udp 17 false 512" NOERROR - 0 5.00013474s
May 11 17:20:52 RPI-HUB ee272bca20e3[680]: [ERROR] plugin/errors: 2 . NS: dial tcp 1.1.1.1:853: connect: connection refused
May 11 17:20:52 RPI-HUB fanShutDownUps.py: [C_UpsCurrent.add_value] Error reading inaBatt registers: 'INA219' object has no attribute '_current_lsb'
May 11 17:20:53 RPI-HUB ee272bca20e3[680]: [INFO] 127.0.0.1:37672 - 12281 "NS IN . udp 17 false 512" NOERROR - 0 5.000206316s
May 11 17:20:53 RPI-HUB ee272bca20e3[680]: [ERROR] plugin/errors: 2 . NS: dial tcp 1.1.1.1:853: connect: connection refused
May 11 17:20:55 RPI-HUB ee272bca20e3[680]: [INFO] 127.0.0.1:34454 - 31403 "NS IN . udp 17 false 512" NOERROR - 0 5.000686562s
May 11 17:20:55 RPI-HUB ee272bca20e3[680]: [ERROR] plugin/errors: 2 . NS: dial tcp 1.1.1.1:853: connect: connection refused
May 11 17:20:56 RPI-HUB ee272bca20e3[680]: [INFO] 127.0.0.1:41421 - 16023 "NS IN . udp 17 false 512" NOERROR - 0 5.000503854s
May 11 17:20:56 RPI-HUB ee272bca20e3[680]: [ERROR] plugin/errors: 2 . NS: dial tcp 1.1.1.1:853: connect: connection refused
May 11 17:20:58 RPI-HUB ee272bca20e3[680]: [INFO] 127.0.0.1:38322 - 51817 "NS IN . udp 17 false 512" NOERROR - 0 5.000687111s
May 11 17:20:58 RPI-HUB ee272bca20e3[680]: [ERROR] plugin/errors: 2 . NS: dial tcp 1.1.1.1:853: connect: connection refused
May 11 17:20:59 RPI-HUB ee272bca20e3[680]: [INFO] 127.0.0.1:45564 - 39430 "NS IN . udp 17 false 512" NOERROR - 0 5.00076285s
May 11 17:20:59 RPI-HUB ee272bca20e3[680]: [ERROR] plugin/errors: 2 . NS: dial tcp 1.1.1.1:853: connect: connection refused
May 11 17:21:01 RPI-HUB ee272bca20e3[680]: [INFO] 127.0.0.1:50227 - 13843 "NS IN . udp 17 false 512" NOERROR - 0 5.000207954s
May 11 17:21:01 RPI-HUB ee272bca20e3[680]: [ERROR] plugin/errors: 2 . NS: dial tcp 1.0.0.1:853: connect: connection refused
May 11 17:21:02 RPI-HUB ee272bca20e3[680]: [INFO] 127.0.0.1:47221 - 53748 "NS IN . udp 17 false 512" NOERROR - 0 5.000355177s
May 11 17:21:02 RPI-HUB ee272bca20e3[680]: [ERROR] plugin/errors: 2 . NS: dial tcp 1.0.0.1:853: connect: connection refused
May 11 17:21:04 RPI-HUB ee272bca20e3[680]: [INFO] 127.0.0.1:39263 - 20306 "NS IN . udp 17 false 512" NOERROR - 0 5.000453614s
May 11 17:21:04 RPI-HUB ee272bca20e3[680]: [ERROR] plugin/errors: 2 . NS: dial tcp 1.0.0.1:853: connect: connection refused
May 11 17:21:05 RPI-HUB ee272bca20e3[680]: [INFO] 127.0.0.1:48895 - 60354 "NS IN . udp 17 false 512" NOERROR - 0 5.000550892s
May 11 17:21:05 RPI-HUB ee272bca20e3[680]: [ERROR] plugin/errors: 2 . NS: dial tcp 1.1.1.1:853: connect: connection refused
May 11 17:21:07 RPI-HUB ee272bca20e3[680]: [INFO] 127.0.0.1:45232 - 41104 "NS IN . udp 17 false 512" NOERROR - 0 5.000709628s
May 11 17:21:07 RPI-HUB ee272bca20e3[680]: [ERROR] plugin/errors: 2 . NS: dial tcp 1.0.0.1:853: connect: connection refused
....

and more of the same. Port number changes all the time. Process id 680:

top - 17:24:52 up  4:29,  2 users,  load average: 3,38, 3,21, 2,81
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
%Cpu(s): 11,5 us, 19,3 sy,  0,0 ni, 54,9 id,  0,0 wa,  0,0 hi, 14,3 si,  0,0 st
MiB Mem :   3882,0 total,    766,9 free,    481,1 used,   2634,0 buff/cache
MiB Swap:   1264,6 total,   1264,6 free,      0,0 used.   3248,6 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                        
  680 root      20   0  957884  58640  36308 S   0,0   1,5   0:36.94 dockerd                                                        

I didn't succeed in copying from HTOP. There would be more info about the process there.

[ArjenR49]

In "current LSB" current seems to mean electrical current and not current as in 'not obsolete, not old'. I suppose current LSB is the amount of electrical current represented by the least significant bit in a multibit digital value which is the result of a current measuring event.

[ArjenR49]

Is this normal? pi-ina219 is found by pip show pi-ina219 from /home/pi/.local/lib/python2.7/site-packages

/home/pi/.local contains site-packages for python2.7, 3.7 and 3.9. pi-ina219.py is present in all of those. it doesn't have a version number or date in the code. pip is only present in python2.7/site-packages.

pip3 is nowhere to be found.

Thonny uses python 3.9.2

Isn't that a bit messy?

pi@RPI-HUB:~ $ pip show pi-ina219
DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 is no longer maintained. pip 21.0 will drop support for Python 2.7 in January 2021. More details about Python 2 support in pip can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support pip 21.0 will remove support for this functionality.
Name: pi-ina219
Version: 1.4.0
Summary: This Python library for Raspberry Pi makes it easy to leverage the complex functionality of the Texas Instruments INA219 sensor to measure voltage, current and power.
Home-page: https://github.com/chrisb2/pi_ina219/
Author: Chris Borrill
Author-email: chris.borrill@gmail.com
License: MIT
Location: /home/pi/.local/lib/python2.7/site-packages
Requires: Adafruit-GPIO, mock
Required-by: 

[frtz13]

does it help to start the script with this command: python3.7 fanShutDownUps.py --notimerbias

[ArjenR49]

In the HAlog I found this recent message. I've seen those before. According to HA there are no problems, though.

2022-05-12 00:30:38 ERROR (MainThread) [homeassistant.components.hassio.handler] Client error on /homeassistant/restart request Server disconnected

[ArjenR49]

There's no command python3.7. python2.7 command is present, but cannot run this code.

pi@RPI-HUB:~/UPSPlus_MQTT $ python3.7 fanShutDownUps.py --notimerbias
bash: python3.7: opdracht niet gevonden
pi@RPI-HUB:~/UPSPlus_MQTT $ python2.7 fanShutDownUps.py --notimerbias
  File "fanShutDownUps.py", line 181
    errMsgFull = "Connection to MQTT broker failed. " + errMsg.get(rc, f"Unknown error: {str(rc)}.")
                                                                                                  ^
SyntaxError: invalid syntax
pi@RPI-HUB:~/UPSPlus_MQTT $ 

pi@RPI-HUB:~/UPSPlus_MQTT $ python3 --version
Python 3.9.2
pi@RPI-HUB:~/UPSPlus_MQTT $ python --version
Python 2.7.18

[ArjenR49]

What is it with the 'no attribute _current_lsb'? I get it with all variations of inaRPi.configure() as below.

...
##        inaRPi.configure()
        inaRPi.configure(inaRPi.RANGE_16V, inaRPi.GAIN_2_80MV, inaRPi.ADC_32SAMP, inaRPi.ADC_32SAMP)
##        inaRPi.configure(inaRPi.RANGE_16V)
...

[frtz13]

are you saying that your scripts cannot get current measures from the ina219 sensor, either? the fanShutdownUPS script will only run on python3. my guess is that the pi-ina219 package (or a dependency) is not correctly installed for the installed python3 version (which apparently is not python 3.7). I suggest to re-install it using pip3. once your own scripts and ~/UPSPlus/Full-featured-demo-code.py execute correctly, try to get fanShutdownUPS.py back up running.

[ArjenR49]

My scripts get all the info from the sensor and the i2c registers, no problem. I don't have pip3 ...

When I try to install it:

sudo apt-get install pip3
Pakketlijsten worden ingelezen... Klaar
Boom van vereisten wordt opgebouwd... Klaar
De statusinformatie wordt gelezen... Klaar 
E: Kan pakket pip3 niet vinden

i.e. package pip3 cannot be found ... ok ... wrong installation command ... try different command ...

pi@RPI-HUB:~ $ sudo apt-get install python3-pip
Pakketlijsten worden ingelezen... Klaar
Boom van vereisten wordt opgebouwd... Klaar
De statusinformatie wordt gelezen... Klaar 
python3-pip is reeds de nieuwste versie (20.3.4-4+rpt1).

i.e python3-pip is already the latest version ....

which pip3 returns nothing

Next move is look for pip3 in /home/pi/.local/lib where there are three python directories with site-packages for v. 2.7, 3.7 and 3.9 ... All have pi-ina219.py Only the python2.7 site-packages contains a pip directory. pip itself is in /home/pi/.local/bin/pip. Actually there are three pip versions there: pip, pip2 and pip2.7. All shell scripts, looking identical, all having python2 on the first lines:

#!/usr/bin/python2
# -*- coding: utf-8 -*-

No pip3 in either of the two python3.* site-packages directories ...

So, I am supposed to have pip3 installed somewhere, but I have not found it, nor does the OS know where it has installed it ...

Next make the Pi search pip3.* in any directory from / down .... taking ages ... Finally the result is a pip3.1 in an archive '/usr/share/man/man1/pip3.1.gz' but it's not what I was looking for, I think, It's much, much larger, over 8 kB, than the other pip files, which are less than 250 bytes ...

.\" Man page generated from reStructuredText.
.
.TH PIP 1 "2014-06-03" "1.5.6" ""
.SH NAME
pip \- A tool for installing and managing Python packages

This was unpacked by me from the archive to see what is inside, so the pip3 that the OS says is installed, is still at large ...

So I removed python3-pip. This took a lot with it. autoremove ... Now I've got pip3, but lost Thonny and python3 ...

So, at this point i could do: pip3 install pi-ina219 to make sure all dependencies are installed.

Well, python3 was apparently still installed - I didn't test running anything on it at this point. Reinstalled thonny. Rebooted .... nothing changed in HA. Same unknown values .. just the fan speed gets updated

[ArjenR49]

So, at this point I got pip3 installed finally, but no change in the HA.

syslog still filling up with very frequent messages from dockerd ...

Is there a connection between HA and docker? For the installation of HA I have used hellresistor's script at the time, part by part. Since then he cut the installation script in parts, too, so one can choose to do only part with his scripts.

The original result was that everything HA, Mosquitto and fanshutdownups worked just fine until HA broke in the beginning of May ...

[frtz13]

what happens if you run the UPSPlus Full-featured-demo-code.py script ? do you get ina219 current measurements in python3 ? once this runs ok, there is a good chance that fanShutdownUPS.py will work, too, and send UPS data to the MQTT broker, from where HA can pick them up.

[ArjenR49]

Oh, but I do get all measurement results using my own Python script with output like this:

/home/pi/UPSPlus_MQTT/UPS_report_for_UPSPlus_mqtt_TEST.py
------------------  13-05-2022 00:44:09  ---------------------------------

*** Data from INA219 at 0x40:
Raspberry Pi supply voltage:                         4,908 V
Raspberry Pi current consumption:                    1,040 A
Raspberry Pi power consumption:                      5,100 W

*** Data from INA219 at 0x45:
Battery voltage:                                     4,204 V
Battery current (charging):                          0,007 A
Power supplied to the batteries:                     0,032 W

*** Remainder of report is based on data collected
*** by the UPS f/w and read from memory at 0x17

UPS board MCU voltage:                               3,287 V   (0x01-0x02)
Voltage at Pi GPIO header pins:                      4,949 V   (0x03-0x04)
USB type C port input voltage:                       9,137 V   (0x07-0x08)
Micro USB port input voltage:                        0,000 V   (0x09-0x0A)

Battery temperature (estimate):                         43°C   (0x0B-0x0C)
Automatic detection of battery type:                   yes     (0x2A)
Batteries fully charged at (UPS/learned value):      4,311 V   (0x0D-0x0E)
Current voltage at battery terminals:                4,212 V   (0x05-0x06)
Discharge limit for use by the control script:       3,200 V   (0x11-0x12)
Batteries fully discharged at (UPS/learned value):   3,330 V   (0x0F-0x10)
Remaining battery capacity (estimate):                  94 %   (0x13-0x14)
Battery sampling ('blue LEDs off') interval:            10 min (0x15-0x16)

Current power state: normal (0x17)

There has never been a problem with getting the data from the UPS that way. What unites the values that I don't get to HA any longer is that they use a value template in the yaml file. The fanspeed doesn't have a value template and it shows up just fine.

On the other hand listening to # also only reports no UPS data, just fanspeed. I expected listening would show unformatted values, but I could be wrong. As a test I would like to eliminate the value template in the yaml file for some other UPS info so that I could see if the problem is with the json stuff. I don't know how to do it, though.

About the errors reported by docker: after much searching I found some info on that. HA wants to connect to Cloudflare on port 853 and this is hard wired. It retries this every second or two, filling up the syslog as a result becaue it fails for a reason I don't know. It seems knowledgeable users have protested to the HA developers that this cannot be changed or disabled. (I use no external access to HA, except using VNC to the server running HA and it's bad practice to meddle with the LAN of the user without a choice/asking) In my router I now made a prerouting rule which forces that traffic to port 853 instead to port 53 on my dns server; in a similar way that I fool a chromecast module into thinking that it contacts 8.8.8.8, where in actual fact the reply comes from my dns server.

# PREROUTING: Force DNS(?) connections from Docker/RPI-HUB intended for Cloudflare port 853
#             to go to port 53 on the PiHole DNS server instead.
iptables -t nat -I PREROUTING -p tcp -s $RPI_HUB --dport 853 -j DNAT --to $DNS0_IPv4:53
iptables -t nat -I PREROUTING -p udp -s $RPI_HUB --dport 853 -j DNAT --to $DNS0_IPv4:53

This made the error messages different - it's crazy, they really come every one or two seconds (!) - now they are tls timeout errors. This is also described on internet sources about HA/docker. Now HA/docker is fooled into thinking it has connections to 1.1.1.1 and 1.0.0.1 on port 853 (reported by my DD-WRT router), but TLS is reportedly too slow and therefore the timeout.

I have a feeling those errors have nothing to do with the problem of most values not showing up in HA. I mean, what business would it be to cloudflare what my UPS reports to a local HA installation. It must be something else.

...
May 13 09:26:02 RPI-HUB 2e6a4ea2e6ac[711]: [INFO] 127.0.0.1:51031 - 64895 "NS IN . udp 17 false 512" NOERROR - 0 30.000577297s
May 13 09:26:02 RPI-HUB 2e6a4ea2e6ac[711]: [ERROR] plugin/errors: 2 . NS: tls: DialWithDialer timed out
May 13 09:26:03 RPI-HUB 2e6a4ea2e6ac[711]: [INFO] 127.0.0.1:50566 - 42609 "NS IN . udp 17 false 512" NOERROR - 0 30.000934975s
May 13 09:26:03 RPI-HUB 2e6a4ea2e6ac[711]: [ERROR] plugin/errors: 2 . NS: tls: DialWithDialer timed out
May 13 09:26:05 RPI-HUB fanShutDownUps.py: [get_UPS_status_and_check_battery_voltage] Error getting data from UPS: [UPSPlus.init] Error reading inaBatt registers: 'INA219' object has no attribute '_current_lsb'
May 13 09:26:05 RPI-HUB 2e6a4ea2e6ac[711]: [INFO] 127.0.0.1:37660 - 12712 "NS IN . udp 17 false 512" NOERROR - 0 30.000697747s
May 13 09:26:05 RPI-HUB 2e6a4ea2e6ac[711]: [ERROR] plugin/errors: 2 . NS: tls: DialWithDialer timed out
May 13 09:26:06 RPI-HUB fanShutDownUps.py: [C_UpsCurrent.add_value] Error reading inaBatt registers: 'INA219' object has no attribute '_current_lsb'
May 13 09:26:06 RPI-HUB 2e6a4ea2e6ac[711]: [INFO] 127.0.0.1:39586 - 8612 "NS IN . udp 17 false 512" NOERROR - 0 30.000514609s
May 13 09:26:06 RPI-HUB 2e6a4ea2e6ac[711]: [ERROR] plugin/errors: 2 . NS: tls: DialWithDialer timed out
May 13 09:26:08 RPI-HUB 2e6a4ea2e6ac[711]: [INFO] 127.0.0.1:52062 - 35351 "NS IN . udp 17 false 512" NOERROR - 0 30.000997443s
May 13 09:26:08 RPI-HUB 2e6a4ea2e6ac[711]: [ERROR] plugin/errors: 2 . NS: tls: DialWithDialer timed out
...

[ArjenR49]

Now that I read about DoT/port 853, it turns out that the above router firewall rules aren't likely to do anything useful.

Got to find info about getting rid of the idiotic stream of error messages somehow in a different way. I do not yet know why DoT over port 853 didn't work without having my misguided firewall rules in place ... The connection was refused, but by whom? Maybe it was timing out in that situation, too, but the response from docker was different.

[frtz13]

are you sure that your script reading UPS current values runs under python3 ?

[ArjenR49]

Yes, I am pretty sure it is.

Usually I run it w/o the python3 command, but there are the shebang lines at the start:

pi@RPI-HUB:~ $ cat /home/pi/UPSPlus_MQTT/UPS_report_for_UPSPlus_mqtt_TEST.py
#!/usr/bin/python3
# -*- coding: utf-8 -*-
...

I just tried it also this way and it works just fine:

pi@RPI-HUB:~ $ python3 /home/pi/UPSPlus_MQTT/UPS_report_for_UPSPlus_mqtt_TEST.py
------------------  13-05-2022 12:11:02  ---------------------------------

*** Data from INA219 at 0x40:
Raspberry Pi supply voltage:                         4,896 V
Raspberry Pi current consumption:                    1,370 A
Raspberry Pi power consumption:                      6,600 W

*** Data from INA219 at 0x45:
Battery voltage:                                     4,204 V
Battery current (charging):                          0,005 A
Power supplied to the batteries:                     0,044 W

*** Remainder of report is based on data collected
*** by the UPS f/w and read from memory at 0x17
...

It won't run on python2.7:

pi@RPI-HUB:~ $ python2.7 /home/pi/UPSPlus_MQTT/UPS_report_for_UPSPlus_mqtt_TEST.py
Traceback (most recent call last):
  File "/home/pi/UPSPlus_MQTT/UPS_report_for_UPSPlus_mqtt_TEST.py", line 14, in <module>
    from smbus2 import SMBus
ImportError: No module named smbus2
pi@RPI-HUB:~ $ 

[frtz13]

can you please try the following: in the "UPS_is_present" function, replace the two inaxxxx.configure() lines with the following: inaRPi.configure(inaRPi.RANGE_32V, inaRPi.GAIN_AUTO, inaRPi.ADC_12BIT, inaRPi.ADC_12BIT) and inaBattery.configure(inaBattery.RANGE_32V, inaBattery.GAIN_AUTO, inaBattery.ADC_12BIT, inaBattery.ADC_12BIT)

[ArjenR49]

THANK YOU, Frtz13! You hit the nail right on its head!

I wanted to try different, supposedly better parameters for the INA219 configuration, but at the start I had obviously copied the same configure line to both positions. So, there was inaRPi instead of inaBattery all the time ... Such a stupid mistake. Too much happening (frequent updates) and new info (deprecation of MQTT parameters) at the same time, and my shallow understanding of HA/Docker/MQTT ... It also hadn't occurred to me to Kompare a previous version of your script with the version in use ...

After the correction your script started working right away :-)

The good thing here is that the python3 installation on this Pi has now been completed with pip3 and the pi-ina219 library also installed for python3, although it doesn't seem to be essential.

In the process I noticed the syslog filling with those annoying DoT error messages that I can now try to eliminate as I found info about them. Thanks a lot!!!

[frtz13]

ok. just be careful not to start another script which configures an ina219 sensor in a different way while fanShutdownUps.py is running.

[ArjenR49]

In case someone ends up in this discussion because of the endless error messages from HA and coredns hogging cpu resources, I should mention the solution here, as it is very short and straightforward:

In a terminal on the server running HA: ha dns options --fallback=false

After wading through endless discussion about the no no of hardwired DNS etc. etc. I found the solution here: https://community.home-assistant.io/t/improve-privacy-stop-using-hardcoded-dns/273496