charlesgodwin / pymagnum Goto Github PK

sometimes, If the magnum reader is invoked shortly after startup, random voltage is applied to the RS-485 device. This can cause unexpected behaviour of devices on the Magnum network, including the inverter.

This will be fixed in release 1.2 2.0 by enforcing a 30 second delay from boot time to ensure a stable system.

The delay can be altered by setting the delay in a predefined variable. Details will be in the release.

In the attached file taken from a run of magtest program, there are three records identified as INVERTER. Lines 10, 30 and 50. But they are not consistent with the definition of an inverter record, they appear to be REMOTE_00 records.

If anyone has a chance, please run off more records to help with my testing. run the command

python3 -m magnum.tools.magtest -n 100 followed by other options.

This will product a test with 00 packets. Add a file with the displayed packets to this issue.

Thanks

misidentifiedpackets.txt

The loop in mqtt client would simplify the code in examples/mqttlogger. This should be researched.

The current program generates a device record every time a request is made via getDevices() method is called. But the situation can occur where there has not been any fresh data provided by a device since the last call. The result is that two or more calls to getDevices() will return exactly the same information and give no indication the device has not reported in this interval.

I intend to add a runtime option to allow detection of this 'non-reporting" and suppress a duplicate, stale record. The default behaviour will remain as before.

Is it possible to change settings using pymagnum suite like done by the ME-ARTR?

There are many fields in the Magnum protocol that are commands to devices. Examples include 'toggle inverter on/off' etc. These are meaningless and unusable for tracking system data and should be removed from the interface.

These fields will be removed in 1.2 for PT-100 and release 2.0 for all others devices.
Release 2.0 will include a description of available variables for each device type.

There seems to be a problem with multi-inverters using the ME-ARTR. I recommended that the Pi connection use ports 5 or 6 of the router. I have had two users reports that only one inverter's data is showing up as a data packet. I have been reading the ARTR owners manual which I found here and selecting it from the Downloads tab. Section 10 discusses setting up a remote ME-ARC remote and emphasizes that the remote can only display one inverter (referred to as a port). Which port you view is changeable, but only one at a time.

I'd like some help from anyone using this software.

Could you extract packets, using magtest, to get inverter data packets. Then, using the ARTR panel select a different port for the ME-ARC, real of imaginary, and repeat the test. I suspect that you will get data from a different inverter. Repeat for each inverter in your system. Please let me now.

Now, what can be done about this? I think the solution is to use a separate RS485/USB dongle for each inverter but I don't know enough yet to make a decision or any suggestions.

I encourage feedback. If you have data, please attach it a file to keep the messages simpler.

Here's what I'm looking for. An Inverter packet looks like this and the 15th byte is the inverter type, master, slave, etc. This should change if I'm right.
Length:21 INVERTER =>400001EC000976B6010033152C1F7301000302580

It's the highlighted >>01<<
Length:21 INVERTER =>400001EC000976B6010033152C1F73>>01<<000302580

BTW I checked on the PT-100 situation and their design is different and I believe, since they are daisy chained, that the data is consolidated.

Hi Charles - I have just completed the project and went to test -- when running magtest I am receiving the following error; any ideas?

Error detected attempting to read network data - test failed Traceback (most recent call last): File "/usr/local/lib/python3.9/dist-packages/magnum/tools/magtest.py", line 49, in main packets = reader.getPackets() File "/usr/local/lib/python3.9/dist-packages/magnum/magnum.py", line 175, in getPackets packets = self.readPackets() File "/usr/local/lib/python3.9/dist-packages/magnum/magnum.py", line 215, in readPackets if self.reader.inWaiting() == 0: File "/usr/lib/python3/dist-packages/serial/serialutil.py", line 594, in inWaiting return self.in_waiting File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 531, in in_waiting s = fcntl.ioctl(self.fd, TIOCINQ, TIOCM_zero_str) OSError: [Errno 25] Inappropriate ioctl for device

I have a fresh install of raspbian on a RPi W. Installed from pip3 and the run of magtest I get this output. Am I missing a package? Do you have a suggestion to fix this issue? Thank you for making this package I am really looking forward to using it.

root@raspberrypi:/home/pi# magtest -d /dev/ttyAMA0 --timeout 0.005
Version:1.1.0
Options:cleanpackets=True, device='/dev/ttyAMA0', packets=50, timeout=0.005
Error detected attempting to read network data - test failed
Traceback (most recent call last):
File "/usr/local/lib/python3.7/dist-packages/magnum/tools/magtest.py", line 47, in main
packets = reader.getPackets()
File "/usr/local/lib/python3.7/dist-packages/magnum/magnum.py", line 124, in getPackets
packets = self.readPackets()
File "/usr/local/lib/python3.7/dist-packages/magnum/magnum.py", line 164, in readPackets
if self.reader.inWaiting() == 0:
File "/usr/lib/python3/dist-packages/serial/serialutil.py", line 590, in inWaiting
return self.in_waiting
File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 467, in in_waiting
s = fcntl.ioctl(self.fd, TIOCINQ, TIOCM_zero_str)
OSError: [Errno 25] Inappropriate ioctl for device

OK, now we get to the interesting part (I figured I'd do it on here so there's public access to the progress, in case someone else wants to do this as well). Here's the gist: I started into this to be able to have local, customized access to monitoring for the Magnums and my Classic 150s (especially the magnums, and without that ridiculously expensive MagWeb) . So eventually, this will need to be fed into a database that I can access easily from a webpage (I haven't even gotten started on the Classics yet simply because I can monitor them right now using the Classic Monitor app on Android, and I don't have any monitoring of the Magnums). That means there will be a server of some kind reading packets at every particular interval (not sure how big that interval will be yet) and writing an average of those packets received to the database. I'd also like to have it able to respond to internet protocol requests of some kind (TCP, HTTP, whatever) with the currently stored latest packet information for a live dashboard. It's quite possible the database might only have datapoints every 5, 15, or even 30 minutes, not quite sure (don't want to populate the database too quickly or densely).

Heck, even if, on your end, all that was made was something to broadcast that periodic data from all available devices on the given channel (JSON would be sufficient), or to give that information easily upon request (again, some web or socket protocol), and configure which RS485s to read from to do it at the same time, that would probably be sufficient.

I've opened the discussion feature so Q&A etc can go there and this can remain only for issues and bugs.

Hi Charles,
I appreciate all you have done for the community and we users of Magnum products.

When I run magserver or magsample with my single MS-4448PAE and ME-ARTR, All readings are in agreement with the ARTR display and believable.

The VAC IN though , at 171 or 172VAC does not reflect the actual measured input of 108 to 115VAC per leg, (or 216 - 230VAC total). It is somewhere in between.

1. Has anyone else reported similar findings? When I read the logs others have posted, the VAC IN is usually 0 (must be in Invert mode - no AC IN connected?) Any idea why this one field is wrong?

2. On a different tangent, I am working on an Arduino web interface to this data thru ethernet shield. Will happily share any of my efforts in this area.
   Also doing an ESP8266 Wifi Web page or UDP packet transfer.

3. Does anyone know if there is an easy way to toggle between INVERT and PASS-THROUGH, say without changing trip point settings in the ARTR? My experience with the Outback inverters suggests this may available without interrupting the AC IN or changing the trip points, as they have a USE or DROP on their remote, and on their web interface.

Again, thank you for all your help to us.

Tom Leitschuh

When the reader detects no connected network it is throwing an error but leaving the serial port open. it should be closed before throwing the error.

Users have reported that the ARTR, used to manage multiple Inverters, does not communicate well when just a Pi is connected to a port. The solution is to use a splitter and share a port with another Magnum device like BMK or AGS-N

Has anyone got knowledge or experience with this

It's bridge from Magnet Network to to an RV Communications protocol used in campers etc.

New research indicates the handling of PT-100 packets is not correct.

The existing code will be upgraded / revised in release 1.2 2.0

The PT-100 JSON is generating values of NaN, which is not universally recognized.

The solution is to suppress data in PT-100 JSION for missing packets.

This is an issue reported on this forum I have moved it here so all can view and or contribute.

`After a bit of messing about, I got it to spit out some info. But only my router. My wires oriented like they are, i can read magnum data with my scripts. I haven't flipped the wires to check with yours but, here is some of the data using your py program.

Options:cleanpackets=True, device='/dev/ttyUSB0', packets=50, timeout=0.001
Length: 5 UNKNOWN =>FC000075BC
Length: 6 UNKNOWN =>01013316221E
Length: 5 UNKNOWN =>7301040002
Length: 4 UNKNOWN =>5900FF00
Length: 6 UNKNOWN =>00DA8A643C20
Length: 5 UNKNOWN =>0000D2BE88
Length: 6 UNKNOWN =>0014005A0078
Length: 3 UNKNOWN =>0478A2
Length: 3 UNKNOWN =>000001
Length: 6 UNKNOWN =>FB000079BB01
Length: 6 UNKNOWN =>013316221E73
Length: 5 UNKNOWN =>0100000259
Length: 3 UNKNOWN =>00FF00
Length:20 UNKNOWN =>00DA8A643C200000D2BE880014602800200A00A3
Length: 2 RTR_91 =>9120
Length:13 UNKNOWN =>000001FB000079BB0100331622
Length: 5 UNKNOWN =>1E73010000
Length: 4 UNKNOWN =>025900FE
Length: 4 UNKNOWN =>0000DA8A
Length: 6 UNKNOWN =>643C200000D2
Length: 5 UNKNOWN =>BE8800143C
Length: 6 UNKNOWN =>3C00200000A4
Length: 4 UNKNOWN =>000001FC
Length: 5 UNKNOWN =>000079BB01
Length: 6 UNKNOWN =>003316221E73
Packets:25 of 50 with 24 UNKNOWN, in 0.75 seconds
`

Currently the example assumes an MQTT broker that supports anonymous users. This enhancement will allow, optionally, to provide user credentials at run time.