print(' '.join(str(v) for v in pz.getData()+[time.time()]))
TypeError: unsupported operand type(s) for +: 'bool' and 'list'
Ok, Thats saying that the getData failed and returned False (boolean) so it cannot attach the list [time.time() to that bool as it expects a list.
you could try wrapping it in a test eg
data = pz.getData()
if data:
print(' '.join(str(v) for v in data +[time.time()]))
But if that getData() returning false that means it is not responding to 5 retries, that doesn’t sound right at all, you could up the retry count to see if it helps, but mine always succeeds on the 1st retry if it fails first attempt.
I do not know if maybe it’s some cut and paste errors or not but it appears there might be some indentation errors in that code.
everything under getData() to the if __name__ line should be indented in one more level and everything below if __name__ to the bottom needs to be indented in 1 level too. Try sorting the indents first as that code looks fine to me, but I’m happy to dig deeper if it does need fixing.
Another possible “difference” is I’m still dev’ing on windows, I haven’t tried it on a Pi yet, and I am also using a different adapter, I haven’t tried the cheap usb adapters that came with the pzems yet.
Actually, I’ve only just noticed you have moved the “x65536” to the other value, I thought you jhad ust reversed the positioning at first glance. I need to think about that some more, there must be some crossed lines about lsb/msb and the array positions. I’ll re read the docs again.
It’s been decades since I did any Modbus work, and that was in C. I think the way I tackled it was to read the complete block of data into a character array that was mapped to the “useful” variables in a union.
A quick search by Mr G threw up this. I don’t understand Python but it looks as if it might circumvent some of the maths.
and that latest table of registers you’ve just posted matches my docs but not your previous post, from what you are saying about the code, it seems the table posted earlier in the thread may be correct.
The next question is are there differences in the device models/revisions or just in the documentation?
I just grabbed this table from the word doc in the pzem docs and utility zip, This would appear to be correct by your findings. However, if your printed docs match this too, then I do not yet know if my devices are the same as yours but supplied with incorrect printed docs or different devices (checked the other box and I have 2 printed docs that both contradict your findings)
Just hooked up a CT to my 016 and got the same issues you had, I have reversed the lsb and msb in the calcs and all is well!
I can’t test the 014 right now as I need a bulb holder or socket with wire tails to wire the monitor in series, I’ll try to check it over the next couple of days.
But with the current findings 2 out of 3 devices say my original code is wrong, so I will post amended versions once I confirm both 014 and 016’s are both the same otherwise I may end up retracting the revised code again to make it work either way depending on a user setting or make separate pzem014 and pzem016 classes, assuming that’s the deciding factor and not vintage or the wind direction on the day of production.
A little excerpt of output, device id 2 is connected to a LED bench magnifier looped 6x through CT. So the load looks like it’s 38w and ramped up a measly 5 watts since I connected it. The power factor is around 0.74.
At least something went right today. I had a crown detach from a molar yesterday.
Went to the dentist to have it re-cemented (not the dentist who originally put it in. This was the 2nd time it became detached) and walked away with a couple of posts in the tooth (endo, so no feeling in the tooth) and a reattached crown. All to the tune of 3 dollars shy of 500 bucks. “Ouch.” said my wallet!
That’s still my preferred way, but I intended to make pzem.py a command line utility as well as a library for bespoke scripts. Plus (for example) it might be nice to check that the energy registers are actually zero immediately after issuing a reset command.
