Posts: 6,222
Threads: 16
Joined: Feb 2020
Obviously the "/" was a typo ("." and "/" are adjacent on the keyboard). You need to trust yourself more.
Python is not much different than any other language I've worked with. The obvious difference is the use of indenting for blocking instead of punctuation or keywords. But COBOL, among others, did the same thing. A more important difference is the ability to change any object at runtime, even functions. But most (all?) dynamic binding style languages allow that.
Posts: 19
Threads: 1
Joined: Mar 2023
At 63 years of age I remember starting my "coding life" in college with Basic, Logo, COBOL, and Pascal...done a lot of other languages since then of course, but I'm liking Python as I dig in a bit. Now that I've retired and live off-grid I have the time (especially in winter when I get snowed in often) to rekindle my interest in coding, so for me that's a good thing...
Regarding your earlier comment about checking the result on the statements...
result = bms.writeCharacteristic(0x15,b'\xdd\xa5\x03\x00\xff\xfd\x77',False)
bms.waitForNotifications(5) I think you're spot on. I'm betting the random issue on occasion is the BMS device being slow to provide a response, and the code doesn't seem to care, it just moves on after 5 seconds. That would result in a "short list" and cause the out of bounds reference error. I'll check the method and see if it provides a usable result code that I can test, and test it. And/or I'll adjust the wait time from 5 seconds to 10 seconds and see if that removes the random fails in the short term. You're correct that once you go down a rat hole like "it must be something strange about the print statements fixing the issue" it can be hard to see other alternatives (wish I had a code buddy to bounce these things off of, but I guess that's what these forums are for).
Again, your thoughtful responses have been enormously helpful!
Posts: 6,222
Threads: 16
Joined: Feb 2020
I write an email to one of my co-workers. Being an email it has to be very detailed and needs a clear description of the problem, what I've tried to solve the problem, information I learned, etc... And then I dump the email in the trash because shifting my focus from what I was doing to describing the problem to someone else usually exposes the real problem. Once you know that the solution is right around the corner.
Posts: 19
Threads: 1
Joined: Mar 2023
Progress, if not a solution yet. I changed the wait time as mentioned above and ran the code several times... Here's the output from two of the runs...
Output: Searching for = 'Cabin 560ah 100a'
=========== Found It ==============
Name = Cabin 560ah 100a
Device = a4:c1:38:f4:bd:25
RSSI = -58 dB
===================================
attempting to connect
connected a4:c1:38:f4:bd:25
In cellinfo1...
13.49 33.83 560.0 456.62
[13.49, 33.83, 560.0, 456.62]
{'rsp': ['wr']}
In cellvolts1...
3372 3375 3374 3379
[13.49, 33.83, 560.0, 456.62, 3372, 3375, 3374, 3379]
{'rsp': ['wr']}
broker disconnected
Searching for = 'Cabin 560ah 100a'
=========== Found It ==============
Name = Cabin 560ah 100a
Device = a4:c1:38:f4:bd:25
RSSI = -58 dB
===================================
attempting to connect
connected a4:c1:38:f4:bd:25
In cellinfo1...
13.49 34.34 560.0 456.94
[13.49, 34.34, 560.0, 456.94]
{'rsp': ['wr']}
{'rsp': ['wr']}
Traceback (most recent call last):
File "/home/pi/Scripts/bms-main/testcode.py", line 148, in <module>
gcellvolt1 = ginfo[4]
IndexError: list index out of range
broker disconnected
You can see that in the first run, which worked, there were to good calls, one to cellinfo1 and one to cellvolts1.
In the second run, which failed, only cellinfo1 was called. And the lack of a good call to cellvolts1 created the missing list arguments and then the out of bounds issue...
So, I'll stop going down the "Print" rat hole and focus on the actual problem! Awesome!!!
The disturbing thing is that both calls give the same result message ( {'rsp': ['wr']} ) so I'll dig into the bluepy library and doco and see why that is. I can't take different actions if the result codes are the same...
Posts: 19
Threads: 1
Joined: Mar 2023
Mar-06-2023, 06:02 PM
(This post was last modified: Mar-06-2023, 06:04 PM by MadMacks.)
Logically, it looks to me like
result = bms.writeCharacteristic(0x15,b'\xdd\xa5\x03\x00\xff\xfd\x77',False)
bms.waitForNotifications(5) is useless in terms of setting a wait time. Once the method call to writeCharacteristic is issued it seems like it will do its thing, and setting a waitForNotifications value is done after the fact. and has no practical value.
On the other hand, the code block
result = bms.writeCharacteristic(0x15,b'\xdd\xa5\x03\x00\xff\xfd\x77',False)
bms.waitForNotifications(5)
result = bms.writeCharacteristic(0x15,b'\xdd\xa5\x04\x00\xff\xfc\x77',False)
bms.waitForNotifications(5) seems like it would read the first set of values (x03 is the trigger) using whatever the default wait time is (probably zero), then set a wait time of 5 seconds for the SECOND call to read the second set of values (x04 is the trigger), and then wait 5 second for that to work. The second waitForNotifications seem useless or redundant.
But i guess it all depends on the bluepy library and how it works.
Posts: 6,222
Threads: 16
Joined: Feb 2020
I couldn't find any documentation saying what is returned by the Peripheral.writeCharacteristic() method.
Posts: 19
Threads: 1
Joined: Mar 2023
(Mar-06-2023, 06:05 PM)deanhystad Wrote: I couldn't find any documentation saying what is returned by the Peripheral.writeCharacteristic() method.
Me either... There really isn't much doco out there for the library. Ugh.
Posts: 19
Threads: 1
Joined: Mar 2023
Mar-06-2023, 06:14 PM
(This post was last modified: Mar-06-2023, 06:15 PM by MadMacks.)
It's bad practice, but I'll throw in some delays between the calls and see if that make it predictable. The BMS' this code is dealing with are cheap Chinese products (and almost all BMS' are) so I'm not hopeful they always respond to bluetooth calls in a timely manor depending on what other processes the BMS is running. That will cause real stability problems for any code base trying to communicate with them. And the bluepy code base isn't all the well defined or documented as far as I can tell...
I've noticed strange delays in getting responses from the BMS' even using the Chinese app that ships with the BMS (XiaoxiangBMS app). Maybe that's the underlaying issue I'm dealing with.
Posts: 6,222
Threads: 16
Joined: Feb 2020
Mar-06-2023, 06:22 PM
(This post was last modified: Mar-06-2023, 06:22 PM by deanhystad.)
The use of a delegate indicates the Bluetooth devices are not meant to be communicated with in a in a predictable sequential manner (they are asynchronous). You send out a request and you may, or may not, receive a reply in the future. If you send multiple requests the replies may not be in the same order as the requests.
I suggest reading this:
http://ianharvey.github.io/bluepy-doc/no...ifications
Notice the example does not assume a notification is sent. It check over and over until one is received.
Posts: 19
Threads: 1
Joined: Mar 2023
I'm going to go back and look more closely at the code tgalarneau originally put up on GitHub. That code seemed to work, even though it put out multiple MQTT messages. In refactoring his code to put out a single MQTT message I may have created the timing issue, as his code seemed to work fine with no "missing messages". That's what I get for jumping in and hacking up his code without fully understanding things.
|
