zigpy / zha-device-handlers

ZHA device handlers bridge the functionality gap created when manufacturers deviate from the ZCL specification, handling deviations and exceptions by parsing custom messages to and from Zigbee devices.
Apache License 2.0
749 stars 687 forks source link

[BUG] Tuya TS0041 TS0042 TS0043 - no battery #2227

Closed provinzio closed 1 year ago

provinzio commented 1 year ago

Describe the bug The Battery value in Home Assistant is always at 100 %. Eventhough I use the switches for over a year now and already had to change the batteries.

To Reproduce Using automatically discorvered quirks e.g. zhaquirks.tuya.ts0042.TuyaSmartRemote0042TO

Expected behavior Correct battery value

Additional context Related fixed issue from zigbee2mqtt https://github.com/Koenkk/zigbee2mqtt/issues/6331 Related misbehavior of the buttons with the quirks https://github.com/zigpy/zha-device-handlers/issues/1746

javicalle commented 1 year ago

Related fixed issue from zigbee2mqtt Koenkk/zigbee2mqtt#6331

The issue is not fixed in Z2M. The fix from your link generated other errors:

and the code has been reverted and is not present in the current version:

Actually the same issue is present in Z2M and not fixed:

From the ZHA quirk point of view I would suggest to remove (in the replacement part) all the PowerConfiguration clusters except from endpoint 1. IE: for the TuyaSmartRemote0042TO quirk:

class TuyaSmartRemote0042TO(CustomDevice):
    """Tuya 2-button remote device with time on out cluster."""

    signature = {
        # SizePrefixedSimpleDescriptor(endpoint=1, profile=260, device_type=0, device_version=1, input_clusters=[0, 1, 6], output_clusters=[10, 25]))
        # SizePrefixedSimpleDescriptor(endpoint=2, profile=260, device_type=0, device_version=1, input_clusters=[1, 6], output_clusters=[])
        MODEL: "TS0042",
        ENDPOINTS: {
            1: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.ON_OFF_SWITCH,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    PowerConfiguration.cluster_id,
                    OnOff.cluster_id,
                ],
                OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
            },
            2: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.ON_OFF_SWITCH,
                INPUT_CLUSTERS: [
                    PowerConfiguration.cluster_id,
                    OnOff.cluster_id,
                ],
                OUTPUT_CLUSTERS: [],
            },
        },
    }
    replacement = {
        ENDPOINTS: {
            1: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.REMOTE_CONTROL,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    PowerConfiguration.cluster_id,
                    TuyaSmartRemoteOnOffCluster,
                ],
                OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
            },
            2: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.REMOTE_CONTROL,
                INPUT_CLUSTERS: [
                    TuyaSmartRemoteOnOffCluster,
                ],
                OUTPUT_CLUSTERS: [],
            },
        },
    }

    device_automation_triggers = {
        (SHORT_PRESS, BUTTON_1): {ENDPOINT_ID: 1, COMMAND: SHORT_PRESS},
        (LONG_PRESS, BUTTON_1): {ENDPOINT_ID: 1, COMMAND: LONG_PRESS},
        (DOUBLE_PRESS, BUTTON_1): {ENDPOINT_ID: 1, COMMAND: DOUBLE_PRESS},
        (SHORT_PRESS, BUTTON_2): {ENDPOINT_ID: 2, COMMAND: SHORT_PRESS},
        (LONG_PRESS, BUTTON_2): {ENDPOINT_ID: 2, COMMAND: LONG_PRESS},
        (DOUBLE_PRESS, BUTTON_2): {ENDPOINT_ID: 2, COMMAND: DOUBLE_PRESS},
    }
MattWestb commented 1 year ago

All TS004X quirks shall being converted to EnchantedDevice for not getting problems with new versions of them and all is remotes like TS004F that is converted.

Likely the magic can fixing this issue 2.

The TS004F we is using the OnOff on out cluster and that is making little problems with defaultresponse that need being sent in reversed direction that ZHA cant doing but i think its not the problem here.

javicalle commented 1 year ago

@provinzio Are you using the quirk from #1746 or is the quirk from latest HA version? @cordvision Do you mind to test the proposed change from https://github.com/zigpy/zha-device-handlers/issues/2227#issuecomment-1446556216 and check the battery behavior?

provinzio commented 1 year ago

@javicalle I am currently using the quirk from the latest HA version

javicalle commented 1 year ago

@javicalle I am currently using the quirk from the latest HA version

Could you try with the custom quirk from https://github.com/zigpy/zha-device-handlers/issues/1746#issuecomment-1437442942

You will need to remove and repair the device after enable the local quirk. Other user is reporting 'jumping' values after apply the quirk. For that behavior I suggest to remove the PowerConfiguration (my previous comment).

provinzio commented 1 year ago

tl;dr I implemented your propsed quirk, a battery level != 100% gets detected which looks promising. Everything else seems normal at first. I will wait for 1-3 days and check in again whether the battery level dropped accordingly and whether the buttons still work as expected


I did the following steps in this order

  1. Downloaded https://github.com/zigpy/zha-device-handlers/issues/1746#issuecomment-1437442942
  2. Adjusted it for 3 buttons ts0043_custom.py.txt
  3. Removed the PowerConfiguration as you said ts0043_custom_removed_PowerConfiguration.py.txt
  4. Uploaded the quirk to Home Assistant
  5. Removed the device in Home Assistant
  6. Repaired the device
  7. Check which quirk was used > "zhaquirks.tuya.ts0043.TuyaSmartRemote0043TO"; thats not my quirk... Do I have to restart HA or something, so that the new quirk can be used?

But, the battery gets detected as 74% which is not 100%. It looks like the repairing did something. Perhaps I wasn't using the latest quirk after all and was stuck with an older quirk?

Clicking the buttons of the switch does not fire an event, automations do not get triggered.

  1. Reload ZHA
  2. Check which quirk was used; now my quirk gets detected > "class": "ts0043_custom_removed_PowerConfiguration.TuyaSmartRemote0043TO"
  3. clicking buttons triggers events anautomations. everything seems normal
  4. I'll test your proposed quirk (see 3) and report back, whether it works.
MattWestb commented 1 year ago

ZHA is only loading quirks then its starting so its not being loaded on the flay. Then the first paring was with the old quirk can you later deleting the remote and waiting one minute and pairing it new and testing how its working ?

Dont hurry we have lot of time until next HA is being released so better doing the test well ;-))

provinzio commented 1 year ago

Ok I will do the following steps and check out whether the device functions normally

  1. Upload Quirk
  2. Reload ZHA
  3. Delete device
  4. Wait 1 minute
  5. Repair device
provinzio commented 1 year ago

Ok I will do the following steps and check out whether the device functions normally

1. Upload Quirk

2. Reload ZHA

3. Delete device

4. Wait 1 minute

5. Repair device

I realized, that the battery is at 100 % after doing this. So this is currently bad when looking at the battery information.

I am out of time for today, I'll try to remove the quirk tomorrow and setup the latest HA quirk, which might have given me the correct battery info (see my post above).

provinzio commented 1 year ago

Quick update. The battery was updated after a while. So I am keeping the proposed quirk and check whether the battery issue (and perhaps also the missing clicks) are fixed with it.

cordvision commented 1 year ago

@javicalle Sorry, I was away for a couple days. I would be happy to test it and report back. I'm a little confused which is the latest quirk that needs testing. Any chance you could upload it as a text file? I have the TS0044 switch (4 buttons / 12 different actions). I just want to avoid editing the quirk myself and possibly introducing issues (I'm fairly new with Home Assistant).

provinzio commented 1 year ago

@cordvision ts0044_custom_removed_PowerConfiguration.py.txt

I am currently testing ts0043_custom_removed_PowerConfiguration. Until now I don't think that I had missing clicks. The battery value is jumping between a value and 100%. Ideas?

grafik

javicalle commented 1 year ago

@provinzio which quirk are you testing? Is the TuyaSmartRemote0043TO from your previous comment? Whitout logs it would be hard to know but it seems that device is reporting double the battery, once with 100% and other (maybe) with the good one.

My assumption was that the extra PowerConfiguration were responsible of it, but the quirk have remove it so... no idea. Could you attach the diagnosis file from your device with the quirk?

Also could be interesting to enable the debug logs and check the battery reports from your device. It is probably that device report itself the battery status over time but maybe also reports when any key is pressed, can you check?

provinzio commented 1 year ago

@javicalle yep TuyaSmartRemote0043TO from ts0043_custom_removed_PowerConfiguration.py.txt

Do you mean this file? If not please give me a hint where I can find the relevant file :) zha-1b4a270315098112f906ebf272ff388d-_TZ3000_gbm10jnj TS0043-4c9b7002357cc58c20cbf2c2afa52d07.json.txt

I find the battery_percentage_remaining value interesting. It's at 140, eventhough the value in Home Assistant says 70 %.

The battery jumping is periodic and also through the night. I don't think that it interacts with any clicks or something else. The 100% value stays ~20 minutes. The "real" value stays for ~40 minutes. Its not exactly 20/40 min but kind of. Which makes a whole cycle of 100 % back to the "real" value ~60 min long. Looks fishy to me, but I have no idea why it does that.

grafik

MattWestb commented 1 year ago

Zigbee is using 1-200 for battery % and 255 is not known so preposition is 0.5%

provinzio commented 1 year ago

I am stuck on this... I updated the quirk for all variants according to your suggestion. All show the same battery behavior.

@javicalle looking for your guidance. Do you have an idea what we could check next? Is it worth to look at the debug logs? I am unfamiliar with that but could dig into it.

MattWestb commented 1 year ago

I only having some TS004F devices but the 4 scene switch is very similar and different and is sending battery report from button 2 or 3 press (i dont remember with).

Can you posting debug log from TS0044 then making pressing of all buttons and waiting 10 seconds between so we can see what the switch is doing (or not) with your updated quirk ?

Then looking on your posted graf i think its normal battery readings. Zigbee is recommending reading the battery then the radio is in stable idle state for not getting the reading stable and i think tuya have not reading that PM. If reading then the radio is active / not stable idle state you is getting higher if the transmission is going well / fast and if its need repeating / waiting the reading is being lower. So i think the reading is OK for the device and its better then Xiaomi that is showing 100% most of the time until they is dead.

If you is getting high readings and can see its moving little up and down i think its all we can getting from the device then its how the device firmware is being done.

nibo2 commented 1 year ago

Pitching in here... I have had ts0044_custom_removed_PowerConfiguration.py.txt installed now for a few days on a wall switch. Same sawtooth 40+20 min cycle pattern as you others.

Here is a snippet from the logs from this night (TS0044 device identifier 0xEF55). Log ZHA TS0044 0xEF55.txt

Some observations in the logs:

nibo2 commented 1 year ago

Log ZHA TS00440xEF55 buttons.txt

Timestamps (c:a):

MattWestb commented 1 year ago

The device is rejoining the network that shall not happening if all things is OK. What is your coordinator type TI or EZSP ? Is the device have the coordinator as it parent or is it having one good or bad router as parent ? Look on the network map after updating it so its current.

And the device is sending one updated battery around 60 min and its OK but its have loosing the contact with the network (somthing is making it thinking that) and after the first rejoining and reporting next reporting is OK 60 min later and then next is start rejoining and sending battery report.

MattWestb commented 1 year ago

flashed 4 LEDs = its rejoining the network :-((

nibo2 commented 1 year ago

I have neither TI or EZSP. It's Dresden.

nibo2 commented 1 year ago

The wall switch device has a good connection to a IKEA TRADFRI bulb, 2m away from it (always on). I have 3 TS0044 units and they all behave the same way. One has the coordinator directly as parent.

cordvision commented 1 year ago

I am stuck on this... I updated the quirk for all variants according to your suggestion. All show the same battery behavior.

@javicalle looking for your guidance. Do you have an idea what we could check next? Is it worth to look at the debug logs? I am unfamiliar with that but could dig into it.

ts0041_custom_removed_PowerConfiguration.py.txt ts0042_custom_removed_PowerConfiguration.py.txt ts0043_custom_removed_PowerConfiguration.py.txt ts0044_custom_removed_PowerConfiguration.py.txt

I uploaded the ts0044 quirk (I of course removed the .txt ending). After re-installing the device and re-starting HA, the custom quirk doesn't seam to have loaded. Under "Zigbee info" for the device, I see "Quirk: zhaquirks.tuya.ts0044.TuyaSmartRemote0044TO". I've used other custom quirks for this device before, and never had that issue. How do I ensure the custom quirk gets loaded?

cordvision commented 1 year ago

@provinzio Do you know if the sleep issue (first button pressed is ignored after a few hours of inactivity) is solved for the ts0044 with the quirk you posted?

MattWestb commented 1 year ago

I cant testing it then my RaspBee is out of function for some time :-((

Is the switch that is having the coordinator as parent doing the strange blinking / rejoining as the other ones ? Also have updated the IKEA lights so they is not running on old bad firmware with routing problems?

I think in the end we need sniffing how the system is setting u the switches in real.

MattWestb commented 1 year ago

@cordvision You see if its loading the quirk in HA log then system is starting if you have debug logging enabled also what quirk the device is getting then the device is loaded of ZHA.

MattWestb commented 1 year ago

@cordvision What coordinator is you using ?

cordvision commented 1 year ago

I'm using a conbee II. Previously and also for other devices, if I go to the device info tab and then click on "zigbee info", I would usually see the custom quirks name. In other words, I would

expect to see this: Quirk: ts0044_custom_removed_PowerConfiguration.py

However, I see this: Quirk: zhaquirks.tuya.ts0044.TuyaSmartRemote0044TO

MattWestb commented 1 year ago

You must looking in the log if its somthing that making the custom quirk is not being loaded or not matching (custom quirks is having higher priority then loading).

For both, what version is the CornBee is running ?

javicalle commented 1 year ago

Pitching in here... I have had ts0044_custom_removed_PowerConfiguration.py.txt installed now for a few days on a wall switch. Same sawtooth 40+20 min cycle pattern as you others.

Here is a snippet from the logs from this night (TS0044 device identifier 0xEF55). Log ZHA TS0044 0xEF55.txt

Some observations in the logs:

* There are two distinctively different sets of packets received from the client in the 40+20 min cycle. I put some blank lines around the interesting bits for readability

* "last_seen" does not seem to be reset ever (?)

* A restart of ZHA, or indeed the entire HA, does not affect the timing of the 40+20 min pattern. Suggesting it is in no way initiated or reset by HA?

After rejoinning, PowerConfiguration cluster is reporting 100% battery but some time after is reporting the 'correct' value. That reports come from the same endpoint, so no mixed endpoints/reports here:

2023-03-07 03:59:15.876 DEBUG (MainThread) [zigpy.zcl] [0xEF55:1:0x0001] Attribute report received: battery_percentage_remaining=200, battery_voltage=30

2023-03-07 04:19:07.270 DEBUG (MainThread) [zigpy.zcl] [0xEF55:1:0x0001] Attribute report received: battery_percentage_remaining=174, battery_voltage=29

2023-03-07 05:01:01.854 DEBUG (MainThread) [zigpy.zcl] [0xEF55:1:0x0001] Attribute report received: battery_percentage_remaining=200, battery_voltage=30

All these availability issues seems to be the cause with the initial 100% battery report.

nibo2 commented 1 year ago

I have access to an IKEA Dirigera hub and will check if temporarily connecting the IKEA bulb will trigger a new firmware update. (Although my ZHA has OTA enabled for ikea_provider but who knows...)

@cordvision there seems to be different versions of the quirk files floating in this thread. This one works for me has power configuration removed in Replacement, not in Signature. It will show as "Quirk: ts0044_custom_removed_PowerConfiguration.TuyaSmartRemote0044TONibo2" in HA GUI device information if loaded.

ts0044_custom_removed_PowerConfigurationNibo2.py.txt

MattWestb commented 1 year ago

@javicalle The log looks OK then both % and V is changing and following each other OK. I think taking away the power config from EP 2 and higher is good if ZHA is configuring reporting of it on all endpoints that can being strange if the device cant handling it OK on not EP1 clusters.

@nibo2 If you is having IKEA OTA enabled in ZHA is working OK and i dont knowing if Dirigera is updating light then i have not seen it but its updating all controllers to 24.5 and we have not getting all fixed so not doing controllers that you have in ZHA then you is loosing some functionality of them.

javicalle commented 1 year ago

The log looks OK then both % and V is changing and following each other OK.

Yes, but it must not report such diferent values over time. They don't come from diferents endpoints, it comes from one endpoint reporting diferent when rejoinning.

I think taking away the power config from EP 2 and higher is good if ZHA is configuring reporting of it on all endpoints that can being strange if the device cant handling it OK on not EP1 clusters.

I agree with that.

provinzio commented 1 year ago

I uploaded the ts0044 quirk (I of course removed the .txt ending). After re-installing the device and re-starting HA, the custom quirk doesn't seam to have loaded. Under "Zigbee info" for the device, I see "Quirk: zhaquirks.tuya.ts0044.TuyaSmartRemote0044TO". I've used other custom quirks for this device before, and never had that issue. How do I ensure the custom quirk gets loaded?

@cordvision I made a mistake with the TS0044 file I uploaded and I removed it from my post now, sorry for that. Please us the file from https://github.com/zigpy/zha-device-handlers/issues/2227#issuecomment-1458077076


@provinzio Do you know if the sleep issue (first button pressed is ignored after a few hours of inactivity) is solved for the ts0044 with the quirk you posted?

It's not solved for me, but... I am still unsure, whether every device of mine is correctly using the quirk. Especially because I haven't removed and repaired all of them. I only repaired most of them; I removed only one one switch before repairing.


My different devices have different battery behavior:

1x TS0041 (ts0041_custom_removed_PowerConfiguration.TuyaSmartRemote0041TOPlusB), 2x TS0042 (ts0042_custom_removed_PowerConfiguration.TuyaSmartRemote0042TO) and 2x TS0043 (ts0043_custom_removed_PowerConfiguration.TuyaSmartRemote0043TO) all had send their battery level 11 h ago (when I repaired them without removing them first) and nothing since then. Looks good to me for now. I have to observe it for a few weeks to see, if it drops accordingly.

1x TS0043 (ts0043_custom_removed_PowerConfiguration.TuyaSmartRemote0043TO) has the sawtooth pattern [this is the device I removed before repairing]

1x TS0043 (ts0043_custom_removed_PowerConfiguration.TuyaSmartRemote0043TO) is still having 100 % at all times

I don't visualy monitor all my devices, so I can't give a precise answer, but I see at least one of my TS0042 flashing on a regular basis. Sometimes it has a missing button click after that, sometimes it does not.

MattWestb commented 1 year ago

My experience with TS004F DMS is still having 100% battery after one year but not so mush used but with one C2034 instead one larger that shall being in it so if not having the rejoining problem the battery can reporting 100% very long time.

provinzio commented 1 year ago

I installed the switches in November and already replaced every battery once. Some switches already have their second battery.

The switches require a lot of energy, unfortunately...

javicalle commented 1 year ago

Definitely these is not a normal behavior. Device would have some kind of problem (maybe keeping rejoining) that exhaust the battery.

provinzio commented 1 year ago

What is the difference when I add a quirk and

  1. Only repair the device. Or
  2. Remove the device, reload ZHA, wait some time and repair the device.

I have the assumption that when I do the first. I get the correct battery curve (or at least a constant value at something below 100%). And when I do the second I get the sawtooth pattern, which might have the correct battery value as it's lower values.

MattWestb commented 1 year ago

Then you is doing changes in the quirk the device is having the old configuration save and its being updated the new parts but old like bindings and reporting is nut updated = its still left and the test is not working OK then its using partly old saved settings in the device. So every time making changes delete the device and restart HA and adding the device new.

@javicalle de(F)conz have digging very deep and the tuya magic is good and deleting the power cluster on EP >1 also but some TS004X device dont like being bond and configured power reporting on any EP. So we need not doing bind and configure of power cluster on this device and the device also EP1 is not getting problems and rejoining all the time. Its looks that the device is reporting battery on key press and also with some hours interval with no binding and reporting of power cluster (as normal with normal tuya Zigbee devices they is not setting up any thing only the magic and they is reporting).

https://github.com/dresden-elektronik/deconz-rest-plugin/pull/6787

Edit: deCONZ have making one PR implanting tuya magic now :-))

MattWestb commented 1 year ago

I was thinking this option can working then its looks Xiaomi is using it and they dont making any reporting config or bindings of there devices. SKIP_CONFIGURATION: True,

javicalle commented 1 year ago

My guess was that the device report is working fine but HA is polling the value (every 60 min or so IIRC) and that part I suspect that is not working and causes the connection drop. Lets explore the SKIP_CONFIGURATION path. I can try a version later. It would be fine to apply to all the TS004X quirks, isn't it?

nibo2 commented 1 year ago

I will test SKIP_CONFIGURATION asap.

But on the whole the basic function of the wall switches has really improved with the new quirk, only rarely getting the first-press-ignored now.

MattWestb commented 1 year ago

I think some TS004F (DMS) is needing it for initializing all "new" endpoints but i think the 41, 42, 43, 44 and 46 shall working OK then they is not having any strange EPs.

I can testing it with the TS004F DMS and ROC if its working OK.

I think i have seen some tuya quirks having it but i dont remember witch it was :-(

nibo2 commented 1 year ago

Initial results for SKIP_CONFIGURATION test:

Seems promising. Hopefully there will be a battery info packet sometime.

MattWestb commented 1 year ago

What i was reading its the switches only reporting battery some time a day or then button is being pressed (i think its depends of the firmware version). Importing is that you is getting updates in some days do there is not not daying without reporting the level is low. Keep observing and look if you is getting rejoining devices or not.

nibo2 commented 1 year ago

Great test results! I have been running SKIP_CONFIGURATION on three TS0044 devices for 18+ hours. Looking at the logs:

ts0044_custom_removed_PowerConfiguration_SKIP_CONFIGURATION.py.txt

MattWestb commented 1 year ago

So far so good and the most importing is is the device have stopping rejoining now and then. If they is not rejoining (after likely firmware crash) it im 110% sure we have fixing the problem only that you also is getting battery reporting little now and then from the remotes.

provinzio commented 1 year ago

I am currently also running the Skip configuration. Since then (15h) I haven't received any updated battery values.

I am currently unsure whether the battery reporting is working (besides the initial value). @nibo2 so you received updated battery values after ~1 day?

nibo2 commented 1 year ago

In my case, my 3 devices are reporting battery about once every 4 hours. They do NOT however show as updated in the HA GUI. Probably because there is no change in value. So that's fine. Logs:

2023-03-09 01:28:15.572 DEBUG (MainThread) [zigpy.zcl] [0x38F0:1:0x0001] Attribute report received: battery_percentage_remaining=172, battery_voltage=29 2023-03-09 01:36:02.299 DEBUG (MainThread) [zigpy.zcl] [0xFC43:1:0x0001] Attribute report received: battery_percentage_remaining=150, battery_voltage=28 2023-03-09 02:03:15.743 DEBUG (MainThread) [zigpy.zcl] [0x3106:1:0x0001] Attribute report received: battery_percentage_remaining=154, battery_voltage=28 2023-03-09 05:25:36.660 DEBUG (MainThread) [zigpy.zcl] [0x38F0:1:0x0001] Attribute report received: battery_percentage_remaining=172, battery_voltage=29 2023-03-09 05:33:28.748 DEBUG (MainThread) [zigpy.zcl] [0xFC43:1:0x0001] Attribute report received: battery_percentage_remaining=150, battery_voltage=28 2023-03-09 06:01:00.218 DEBUG (MainThread) [zigpy.zcl] [0x3106:1:0x0001] Attribute report received: battery_percentage_remaining=154, battery_voltage=28 2023-03-09 09:22:52.531 DEBUG (MainThread) [zigpy.zcl] [0x38F0:1:0x0001] Attribute report received: battery_percentage_remaining=172, battery_voltage=29 2023-03-09 09:31:05.316 DEBUG (MainThread) [zigpy.zcl] [0xFC43:1:0x0001] Attribute report received: battery_percentage_remaining=150, battery_voltage=28 2023-03-09 09:58:39.322 DEBUG (MainThread) [zigpy.zcl] [0x3106:1:0x0001] Attribute report received: battery_percentage_remaining=154, battery_voltage=28