PiSugar / pisugar-power-manager-rs

PiSugar Power Manger in rust language
https://www.pisugar.com/
GNU General Public License v3.0
130 stars 15 forks source link

[BUG] Raspberry pi zero 2 with pisugar2 #44

Open Jesstr8803 opened 2 years ago

Jesstr8803 commented 2 years ago

Environment

To Reproduce Steps to reproduce the behavior: After installing 1.5.0 of piserver using curl http://cdn.pisugar.com/release/Pisugar-power-manager.sh | sudo bash The battery seems to communicated fine with raspberry pi, can request any battery flag using nc -U /tmp/pisugar-server.sock and then typing in a request. But the RTC return nothing but Invalid request.

Expected behavior Should be able to request data from RTC

Screenshots If applicable, add screenshots to help explain your problem.

Additional context I2C tools shows both i2c addresses.

pi@DropCam:~ $ sudo nc -U /tmp/pisugar-server.sock
get model
model: PiSugar 2 (2-LEDs)
get rtc_alarm_time
Invalid request.
get rtc_time
Invalid request.
get battery_i
battery_i: -0.17294818
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- 32 -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- 75 -- --
pi@DropCam:~ $ i2cdump -y 1 0x32
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 13 38 a1 01 20 12 21 00 13 21 7f 20 12 21 00 00    ?8?? ?!.?!? ?!..
10: 52 0b 00 00 93 79 bf bf 02 be fb eb fe df eb ff    R?..?y?????????.
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
 i2cdump -y 1 0x75
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: ea fe 7b 68 37 00 9d 00 00 04 7e 62 4b 00 00 00    ??{h7.?..?~bK...
10: d9 ba 01 00 80 33 00 84 00 00 00 00 00 00 00 00    ???.?3.?........
20: fa 2e 52 48 85 d7 b0 93 00 00 00 00 00 00 00 00    ?.RH????........
30: fe b4 52 ab 9c 9d 85 4a fd 6d 14 00 00 00 00 00    ??R????J?m?.....
40: 51 0a 11 23 d5 00 00 00 00 00 1f 55 01 00 00 00    Q??#?.....?U?...
50: 05 14 04 12 04 00 00 00 00 00 00 00 00 00 00 00    ?????...........
60: 00 00 00 00 00 00 ff 00 00 00 00 00 00 00 00 00    ................
70: 25 00 1c e0 1b 00 0c 01 00 00 01 70 03 06 00 11    %.???.??..?p??.?
80: 53 66 86 af 5a 72 a4 5f 91 00 00 00 00 00 00 00    Sf??Zr?_?.......
90: 7f 8c a6 d0 84 97 c4 87 b0 00 00 00 00 00 00 00    ?????????.......
a0: 99 0f 07 14 cc 3e 44 2c fa 13 10 12 0d 1a 00 00    ?????>D,??????..
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

I tried using all the different versions of PiSugar server/power manager from 1.5.0 to 1.6.3, they all gave different results, I could almost make it work with 1.6.3, but I would have to go back and manually configure /etc/defaults/pisugar-server, and /etc/pisugar-server/config.json, as the default file was messed up because of the OSD menu(not actually sure what it is called, but it's the blue screen) that asks about the type of PiSugar, and the login for the config.json was messed up, the user would say OK, I'm thinking its becasue of the OSD menu. But when I did this I could communicate with the RTC, but the behaviour wasn't right either. When setting the alarm the time would populate correctly but the date would always have the year 2020 or 1999. I also tried installing 1.6.3 then down grading to 1.5, and it would work better the dates would still be messed up.

Not sure what is causing the breakdown, In the meantime ive gone back to using a Pi Zero. I would love to be able to use my Pi Zero 2 as it is much faster, although a little more power hungry. But for my application which is a long duration timelapse, I need to be able to boot fast take a picture and and shutdown fast. then wait until the next photo to start the cycle again.

image

Update: I started a new install of Buster on the Zero 2, and installed PiSugar software using : wget http://cdn.pisugar.com/release/pisugar-power-manager.sh sudo bash pisugar-power-manager.sh -c release

Installed version 1.6.3, like I stated earlier it would mess up the config.json and deafult/pisugar-server file. Below is what it reports:

Config.JSON - think it's pulling info from the OSD for the auth. I usually change it back to admin, admin. Or as you see later I'll just disabled it.

{
  "digest_auth": [
    "ok",
    "admin"
  ],
  "i2c_bus": 1,
  "auto_wake_time": null,
  "auto_wake_repeat": 0,
  "single_tap_enable": false,
  "single_tap_shell": "",
  "double_tap_enable": false,
  "double_tap_shell": "",
  "long_tap_enable": false,
  "long_tap_shell": "",
  "auto_shutdown_level": 0,
  "auto_shutdown_delay": 0,
  "auto_charging_range": [
    80,
    100
  ],
  "full_charge_duration": null,
  "auto_power_on": false,
  "auto_rtc_sync": false
}

This is the contents of the /etc/default.pisugar-server file

OPTS=--config config.json --model '20 Unsupported command "/usr/bin/raspi-config" (full line was "/usr/bin/raspi-config") received from confmodule.' --tcp PiSugar 2 (2-LEDs):8423 --uds /tmp/pisugar-server.sock

So I cahnged it to:

OPTS="--model 'PiSugar 2 (2-LEDs)' --syslog --config config.json --uds /tmp/pisugar-server.sock --tcp 0.0.0.0:8423 --ws 0.0.0.0:8422 --web /usr/share/pisugar-server/web --http 0.0.0.0:8421"

After fixing up these files I'll send the following to disable the auth : echo "set_auth" | nc -q 0 127.0.0.1 8423

And as you can see it is working. Well mostly, there seems to be an issue with the alarm date, but the RTC will communicate now.

image

Here you can see that the alarm set is accepted but when reported back the date is wrong:

pi@DropCam:~ $ sudo nc -U /tmp/pisugar-server.sock
get battery
battery: 95.91772
get model
model: PiSugar 2 (2-LEDs)
rtc_alarm_set 2021-12-20T17:00:00-07:00 127
rtc_alarm_set: done
get rtc_alarm_time
rtc_alarm_time: 1999-12-31T17:00:00-07:00
get rtc_time
rtc_time: 2021-12-20T16:54:14-07:00
rtc_web
rtc_web: done
get rtc_time
rtc_time: 2021-12-20T16:54:26-07:00
get rtc_alarm_enabled
rtc_alarm_enabled: true

Hope this helps you guys!

fengyc commented 2 years ago

@Jesstr8803 Thanks for the report.

If the pisugar2 rtc keep reporting lots of xxs, that means the hardware has some problem, please contact pisugar.zerogmail.com for further support.

The error in /etc/default/pisugar-server had been fixed in the latest development build, you could install the latest one and test again.

Jesstr8803 commented 2 years ago

@fengyc Thanks for getting back to me, I was able to try 1.6.4 and that version seemed to fix the /etc/default/pisugar-server and the web authorization login. But I am still having issues with the date reporting back correctly with the rtc_alarms. I have contacted the email provided. Thank you fengyc. I also have a couple more boards on order, ,so when I recieve them I can do more testing!

Jesstr8803 commented 2 years ago

@fengyc I have contacted the email provided, and they said that having the XX in the RTC is ok and it should not affect the function of the RTC as the important information is at the top of the register. Looking forward to the next update, hopefully you can figure out the date issue with the alarms!

fengyc commented 2 years ago

Could you update the rtc and set up a wake up alarm via web ui ?

rtc_alarm_time: 1999-12-31T17:00:00-07:00 is UTC 2000-01-01T00:00:00, the pisugar-server would return this value if the data of rtc is incorrect.

Jesstr8803 commented 2 years ago

@fengyc, I can set the time correctly from both the Web UI and using the socket. But the date still comes back incorrectly.

pi@DropCam:~ $  sudo nc -U /tmp/pisugar-server.sock
get rtc_alarm_time
rtc_alarm_time: 2000-01-01T13:47:00-07:00
rtc_alarm_set 2021-12-31T13:48:00-07:00 127
rtc_alarm_set: done
get rtc_alarm_time
rtc_alarm_time: 2000-01-01T13:48:00-07:00

eg. image

get rtc_alarm_time
rtc_alarm_time: 2000-01-01T13:51:00-07:00
fengyc commented 2 years ago

@Jesstr8803 The rtc_alarm_time value is correct. Only the hh:MM:ss and the weekday repeat values could control the rtc alarm, the yyyy/mm/dd part of rtc_alarm_time would be ignored.

Jesstr8803 commented 2 years ago

@fengyc, Sorry for taking so long to get back, Thanks for all your help! Just out of curiosity, did the date report correctly in a previous version? maybe 1.5?

fengyc commented 2 years ago

@Jesstr8803 No.

My plan is to add a new feature to allow setting the year and month of the alarm datetime, but I am not sure whether the RTC chip could support this feature. Will update the code if I make it work.