September 6, 20169 yr Author 20 minutes ago, SilverNodashi said: Thanx I did try this, but still got no response back from the inverter. Ugh! I am beginning to think there's something wrong with the USB to serial adapter I'm using. I'll make connect a cable directly to the serial pins tomorrow and see if that works.The Axpert remove interface works fine, so the serial port in the inverter works fine as well. Tested the laptop, on the exact same cable and WatchPower works fine. So the cables and the inverter comms port is fine. So this is either a Linux issue, or a USB -> Serial issue. Will see if I can get a Linux PC going as an alternative test, or use the Raspberry Pi serial pins directly. Tomorrow, or the next day
September 7, 20169 yr If you use the RPI TTL serial directly just keep in mind that it's 3.3V and it is not 5V tolerant. I don't know what level the axpert uses. Tx is usually fine, 3V or so counts as a 1 even in a 5V system, but you'll have to put a voltage divider on the Rx side if there is a mismatch. Sent from my GT-I9195 using Tapatalk
September 7, 20169 yr 7 hours ago, SilverNodashi said: Ugh! I am beginning to think there's something wrong with the USB to serial adapter I'm using. You've posted some text yesterday, I assume from the terminal emulator screen, which included (NAKss and then I told you that that is the inverter's response to tell you that it did not understand the command sent to it - that means that the comms to the inverter is working.
September 7, 20169 yr Author Just now, superdiy said: You've posted some text yesterday, I assume from the terminal emulator screen, which included (NAKss and then I told you that that is the inverter's response to tell you that it did not understand the command sent to it - that means that the comms to the inverter is working. Yes, I figured that much as well, but can't figure out why sending commands, from RPI doesn't return any values. Here's the full picture, as it stands: - On a Windows XP PC, Wathtower works fine. This is either through the PC's serial port, using the Axpert serial cable, to the inverter's serial port, or though a USB to serial cable, connected to the Axper serial cable. (http://www.takealot.com/trendnet-usb-to-serial-converter/PLID29271821) - On my Windows 7 laptop, Watchtower and AICC works fine. My laptop doesn't have serial, so I used the serial to USB cable (http://www.takealot.com/trendnet-usb-to-serial-converter/PLID29271821) - When using the Raspberry Pi, with plonkster's code, I get the following: pi@raspberrypi:~ $ python plonkster.py /dev/ttyUSB0 QPI 515049beac [] pi@raspberrypi:~ $ python plonkster.py /dev/ttyUSB0 QPIGS 5150494753b7a9 [] pi@raspberrypi:~ $ ll /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0 lrwxrwxrwx 1 root root 13 Sep 7 01:17 /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0 -> ../../ttyUSB0 pi@raspberrypi:~ $ sudo python plonkster.py /dev/ttyUSB0 QPIGS 5150494753b7a9 [] Feeding the commands to the inverter, using picocom, trying any method I could think of (i.e. ACII, HEX, combination of the two) didn't yield more than the "NAKss" response. This last bit tells me the inverter gets the commands, and send a response, albeit not any values I wanted to see. SO, now I'm stuck with not knowing if the USB drivers in Linux modifies the commands in a way, or whether the terminal modifies it. I'm access the Pi through SSH, so not sure if Putty messes up my key strokes or not. At this stage the only other options I have is to try a Linux PC, with a serial port and see what I get from it. Or hookup a keyboard and monitor to the Pi, in the garage and see if that helps at all.
September 7, 20169 yr Author 39 minutes ago, TinkerBoy said: I am confused. You told us Watchpower also does not work. Now it works ? Yes, you are right. I am an idiot. I ran a 30m CAT5 cable from the inverter to my workshop but didn't realize at that time that pin 6 in the cable is swapped around. Once I setup everything in the garage again, comms was fine. so I just need to cut that RJ45 jack off and put a new one on. When I get to a shop to buy one, on day.
September 7, 20169 yr Author 18 hours ago, TinkerBoy said: But hey, we should charge him consulting fees for the help LOL. I did actually say, in my first post that I am more than willing to pay. Not sure why this is brought up?
September 7, 20169 yr Author 18 hours ago, TinkerBoy said: But hey, we should charge him consulting fees for the help LOL. I did actually say, in my first post that I am more than willing to pay. Not sure why this is brought up?
September 7, 20169 yr Author 22 hours ago, Coulomb said: The trouble with ASCII characters that have the sign (most significant) bit set is that there is no standard on how to send them or even how tp display them. For example, in superdiy's post, the CRC values B7 and A9 come out on my phone as a centred dot and a copyright symbol. I bet others have seen them as other characters. On my favourite terminal program, TeraTerm, you send such characters using the right-alt key in combination with another key. For example, B7 = 80 + 37 (in hex), so 37 is B7 with the sign bit stripped off. From any ascii table, the character whose hex representation id 37 is '7' (the seven character), do you can send B7 (in TeraTerm, when it is set up correctly) by pressing right-alt and the 7 key together (use right-alt like a shift or control key). Similarly A9 is right-alt and ')' (i.e. shift zero on most keyboards). You can't type QPIGS without the CRC characters, or by typing thr two hex characters (e.g. 5 and 1 for Q). If you have a terminal program where you can send everything in hex, then don't forget to add 0D at the end for a carriage return. These things are difficult to explain on a forum, bit once you get the idea, and have the right software tools, it's pretty easy. Ok, so I re-read this, in the morning when my mind is still fresh and used a HEX to ASCII table to get the corresponding ACII keys for the CRC, entered them, and still get the NAKss error: picocom v1.7 port is : /dev/ttyUSB0 flowcontrol : none baudrate is : 2400 parity is : none databits are : 8 escape is : C-a local echo is : yes noinit is : no noreset is : no nolock is : no send_cmd is : sz -vv receive_cmd is : rz -vv imap is : omap is : emap is : crcrlf,delbs, Terminal ready QPIGS·© (NAKss The keystrokes I entered was: "QPIGS"+"ALT+183"+"ALT+169"+"ALT+13" -> which I really do think is / was "QPIGS"+"0xB7"+"0xA9"+"0D". I also tried it without the "0D" at the end, and just pressed enter, same "NAKss" comes up. BUT when I type in "ALT+13" (i.e. hex "0D" to Ascii) I get "AKss": AKss So, is the CRC is correct? OR does it get changed somewhere on the wire? I mean, literally, on the wire between Putty -> Pi -> USB-to-serial -> Axpert Serial cable.
September 7, 20169 yr 58 minutes ago, SilverNodashi said: I did actually say, in my first post that I am more than willing to pay. Not sure why this is brought up? He's messing with you... after that spat you and whatshisname had that time. I don't think he was serious :-)
September 7, 20169 yr 27 minutes ago, SilverNodashi said: So, is the CRC is correct? OR does it get changed somewhere on the wire? I mean, literally, on the wire between Putty -> Pi -> USB-to-serial -> Axpert Serial cable. Line termination maybe. Windows uses CR-LF. Unix uses only LF (ascii 10, 0x0A), and I've seen OSX sometimes use only CR. Depending on terminal settings and a whole bunch of things the inverter might not be getting what it expects to terminate the line, either getting an unexpected extra CR in front of the LF, or not getting the CR it was looking for. Depends what the inverter wants. The code I gave you actually doesn't add the CR. That might be the problem at least there. So just fix this line: result = cmd + pack(">H", checksum) + '\n' \n is a carriage return (ascii 0x0D). \r is a newline (Ascii 0x0A). You can also try \r\n (carriage return, newline) which is the traditional DOS line-ending. The pyserial method gives you complete control of what passes over the wire and there is no modification in the drivers at all.
September 7, 20169 yr Also, no need to use sudo. The pi user should be in the dialout group already which will give it write access to serial ports. Just type "groups" to check. If the user is not in the dialout group, type: "sudo adduser pi dialout", then log out and back in. Then you don't have to use sudo to access the serial port. It's a unix thing... we kinda frown upon doing everything as root (aka administrator).
September 7, 20169 yr Author 7 minutes ago, plonkster said: Line termination maybe. Windows uses CR-LF. Unix uses only LF (ascii 10, 0x0A), and I've seen OSX sometimes use only CR. Depending on terminal settings and a whole bunch of things the inverter might not be getting what it expects to terminate the line, either getting an unexpected extra CR in front of the LF, or not getting the CR it was looking for. Depends what the inverter wants. The code I gave you actually doesn't add the CR. That might be the problem at least there. So just fix this line: result = cmd + pack(">H", checksum) + '\n' \n is a carriage return (ascii 0x0D). \r is a newline (Ascii 0x0A). You can also try \r\n (carriage return, newline) which is the traditional DOS line-ending. The pyserial method gives you complete control of what passes over the wire and there is no modification in the drivers at all. Ok, so neither "\n" or "\r\n" worked pi@raspberrypi:~ $ vim plonkster.py ; python plonkster.py /dev/ttyUSB0 QPIGS 5150494753b7a90a [] pi@raspberrypi:~ $ grep resul plonkster.py result = cmd + pack(">H", checksum) + '\n' print result.encode('hex') port.write(result) pi@raspberrypi:~ $ vim plonkster.py ; python plonkster.py /dev/ttyUSB0 QPIGS 5150494753b7a90d0a ['(', 'N', 'A', 'K', 's', 's', '\r'] pi@raspberrypi:~ $ grep resul plonkster.py result = cmd + pack(">H", checksum) + '\r\n' print result.encode('hex') port.write(result) So I ran the command with strace, and noticed this: fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76fe1000 write(1, "5150494753b7a90a\n", 175150494753b7a90a ) = 17 open("/dev/ttyUSB0", O_RDWR|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = 3 ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B2400 -opost -isig -icanon -echo ...}) = 0 write(3, "QPIGS\267\251\n", 8) = 8 select(4, [3], [], [], {10, 0}) = 0 (Timeout) write(1, "[]\n", 3[] ) = 3 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x76d8d180}, {0x1275a8, [], SA_RESTORER, 0x76d8d180}, 8) = 0 close(3) = 0 exit_group(0) = ? +++ exited with 0 +++ And now I'm going to bang my head against a wall somewhere for not having taken computer classes in school. Or in college... "Should have learned to program!" "Should have learned to read HEX!" "Should not have wasted time building mobile disco shit!"
September 7, 20169 yr Author 7 minutes ago, plonkster said: Line termination maybe. Windows uses CR-LF. Unix uses only LF (ascii 10, 0x0A), and I've seen OSX sometimes use only CR. Depending on terminal settings and a whole bunch of things the inverter might not be getting what it expects to terminate the line, either getting an unexpected extra CR in front of the LF, or not getting the CR it was looking for. Depends what the inverter wants. The code I gave you actually doesn't add the CR. That might be the problem at least there. So just fix this line: result = cmd + pack(">H", checksum) + '\n' \n is a carriage return (ascii 0x0D). \r is a newline (Ascii 0x0A). You can also try \r\n (carriage return, newline) which is the traditional DOS line-ending. The pyserial method gives you complete control of what passes over the wire and there is no modification in the drivers at all. Ok, so neither "\n" or "\r\n" worked pi@raspberrypi:~ $ vim plonkster.py ; python plonkster.py /dev/ttyUSB0 QPIGS 5150494753b7a90a [] pi@raspberrypi:~ $ grep resul plonkster.py result = cmd + pack(">H", checksum) + '\n' print result.encode('hex') port.write(result) pi@raspberrypi:~ $ vim plonkster.py ; python plonkster.py /dev/ttyUSB0 QPIGS 5150494753b7a90d0a ['(', 'N', 'A', 'K', 's', 's', '\r'] pi@raspberrypi:~ $ grep resul plonkster.py result = cmd + pack(">H", checksum) + '\r\n' print result.encode('hex') port.write(result) So I ran the command with strace, and noticed this: fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76fe1000 write(1, "5150494753b7a90a\n", 175150494753b7a90a ) = 17 open("/dev/ttyUSB0", O_RDWR|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = 3 ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B2400 -opost -isig -icanon -echo ...}) = 0 write(3, "QPIGS\267\251\n", 8) = 8 select(4, [3], [], [], {10, 0}) = 0 (Timeout) write(1, "[]\n", 3[] ) = 3 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x76d8d180}, {0x1275a8, [], SA_RESTORER, 0x76d8d180}, 8) = 0 close(3) = 0 exit_group(0) = ? +++ exited with 0 +++ And now I'm going to bang my head against a wall somewhere for not having taken computer classes in school. Or in college... "Should have learned to program!" "Should have learned to read HEX!" "Should not have wasted time building mobile disco shit!"
September 7, 20169 yr Author 12 minutes ago, plonkster said: Also, no need to use sudo. The pi user should be in the dialout group already which will give it write access to serial ports. Just type "groups" to check. If the user is not in the dialout group, type: "sudo adduser pi dialout", then log out and back in. Then you don't have to use sudo to access the serial port. It's a unix thing... we kinda frown upon doing everything as root (aka administrator). Yea, "pi" is part of the "dialouts" group. Just tried sudo to see if there were other permissions somewhere that might not get elevated properly.
September 7, 20169 yr Author 7 minutes ago, plonkster said: Line termination maybe. Windows uses CR-LF. Unix uses only LF (ascii 10, 0x0A), and I've seen OSX sometimes use only CR. Depending on terminal settings and a whole bunch of things the inverter might not be getting what it expects to terminate the line, either getting an unexpected extra CR in front of the LF, or not getting the CR it was looking for. Depends what the inverter wants. The code I gave you actually doesn't add the CR. That might be the problem at least there. So just fix this line: result = cmd + pack(">H", checksum) + '\n' \n is a carriage return (ascii 0x0D). \r is a newline (Ascii 0x0A). You can also try \r\n (carriage return, newline) which is the traditional DOS line-ending. The pyserial method gives you complete control of what passes over the wire and there is no modification in the drivers at all. Ok, so neither "\n" or "\r\n" worked pi@raspberrypi:~ $ vim plonkster.py ; python plonkster.py /dev/ttyUSB0 QPIGS 5150494753b7a90a [] pi@raspberrypi:~ $ grep resul plonkster.py result = cmd + pack(">H", checksum) + '\n' print result.encode('hex') port.write(result) pi@raspberrypi:~ $ vim plonkster.py ; python plonkster.py /dev/ttyUSB0 QPIGS 5150494753b7a90d0a ['(', 'N', 'A', 'K', 's', 's', '\r'] pi@raspberrypi:~ $ grep resul plonkster.py result = cmd + pack(">H", checksum) + '\r\n' print result.encode('hex') port.write(result) So I ran the command with strace, and noticed this: fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76fe1000 write(1, "5150494753b7a90a\n", 175150494753b7a90a ) = 17 open("/dev/ttyUSB0", O_RDWR|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = 3 ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B2400 -opost -isig -icanon -echo ...}) = 0 write(3, "QPIGS\267\251\n", 8) = 8 select(4, [3], [], [], {10, 0}) = 0 (Timeout) write(1, "[]\n", 3[] ) = 3 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x76d8d180}, {0x1275a8, [], SA_RESTORER, 0x76d8d180}, 8) = 0 close(3) = 0 exit_group(0) = ? +++ exited with 0 +++ And now I'm going to bang my head against a wall somewhere for not having taken computer classes in school. Or in college... "Should have learned to program!" "Should have learned to read HEX!" "Should not have wasted time building mobile disco shit!"
September 7, 20169 yr Author 12 minutes ago, plonkster said: Also, no need to use sudo. The pi user should be in the dialout group already which will give it write access to serial ports. Just type "groups" to check. If the user is not in the dialout group, type: "sudo adduser pi dialout", then log out and back in. Then you don't have to use sudo to access the serial port. It's a unix thing... we kinda frown upon doing everything as root (aka administrator). Yea, "pi" is part of the "dialouts" group. Just tried sudo to see if there were other permissions somewhere that might not get elevated properly.
September 7, 20169 yr Author 7 minutes ago, plonkster said: Line termination maybe. Windows uses CR-LF. Unix uses only LF (ascii 10, 0x0A), and I've seen OSX sometimes use only CR. Depending on terminal settings and a whole bunch of things the inverter might not be getting what it expects to terminate the line, either getting an unexpected extra CR in front of the LF, or not getting the CR it was looking for. Depends what the inverter wants. The code I gave you actually doesn't add the CR. That might be the problem at least there. So just fix this line: result = cmd + pack(">H", checksum) + '\n' \n is a carriage return (ascii 0x0D). \r is a newline (Ascii 0x0A). You can also try \r\n (carriage return, newline) which is the traditional DOS line-ending. The pyserial method gives you complete control of what passes over the wire and there is no modification in the drivers at all. Ok, so neither "\n" or "\r\n" worked pi@raspberrypi:~ $ vim plonkster.py ; python plonkster.py /dev/ttyUSB0 QPIGS 5150494753b7a90a [] pi@raspberrypi:~ $ grep resul plonkster.py result = cmd + pack(">H", checksum) + '\n' print result.encode('hex') port.write(result) pi@raspberrypi:~ $ vim plonkster.py ; python plonkster.py /dev/ttyUSB0 QPIGS 5150494753b7a90d0a ['(', 'N', 'A', 'K', 's', 's', '\r'] pi@raspberrypi:~ $ grep resul plonkster.py result = cmd + pack(">H", checksum) + '\r\n' print result.encode('hex') port.write(result) So I ran the command with strace, and noticed this: fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76fe1000 write(1, "5150494753b7a90a\n", 175150494753b7a90a ) = 17 open("/dev/ttyUSB0", O_RDWR|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = 3 ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B2400 -opost -isig -icanon -echo ...}) = 0 write(3, "QPIGS\267\251\n", 8) = 8 select(4, [3], [], [], {10, 0}) = 0 (Timeout) write(1, "[]\n", 3[] ) = 3 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x76d8d180}, {0x1275a8, [], SA_RESTORER, 0x76d8d180}, 8) = 0 close(3) = 0 exit_group(0) = ? +++ exited with 0 +++ And now I'm going to bang my head against a wall somewhere for not having taken computer classes in school. Or in college... "Should have learned to program!" "Should have learned to read HEX!" "Should not have wasted time building mobile disco shit!"
September 7, 20169 yr 2 minutes ago, SilverNodashi said: write(3, "QPIGS\267\251\n", 8) = 8 267 and 251 in this case is octal. so 267 = 0xB7, 251 = 0xA9. Easy way to do that in linux using the bc commandline calculator: bc ibase=8 obase=20 Then type in 267 and it will spit out B7. (Why obase=20? Well, because ibase is now 8, and 20_8 == 16_10 :-) ).
September 7, 20169 yr Author Just now, plonkster said: 267 and 251 in this case is octal. so 267 = 0xB7, 251 = 0xA9. Easy way to do that in linux using the bc commandline calculator: bc ibase=8 obase=20 Then type in 267 and it will spit out B7. (Why obase=20? Well, because ibase is now 8, and 20_8 == 16_10 :-) ). Ok, fair enough. But why the change? Does the inverter then actually expect octal characters, or hex?
September 7, 20169 yr Also, you can change the timeout in my code from one second to None, eg timeout=None. Then it will never time out and you will have to hit ctrl+C. But then the cheeky iter() code at the end is going to break too, you'll have to do something like: # Instead of this: i = iter(lambda: port.read(1), '') print list(i) # Do this. while True: x = port.read(1) print x Perhaps the one second timeout isn't enough for the inverter to respond. 2 minutes ago, SilverNodashi said: Ok, fair enough. But why the change? Does the inverter then actually expect octal characters, or hex? No distinction on the wire. By the time it hits the wire it's all ones and zeroes. Don't be confused, whether you write 0268 (traditionally a leading zero means octal) or 0xB7 or 183 (decimal) the low level stuff don't care. Writing it in HEX makes it group better visually, because two hex digits is exactly 8 bits, writing it in octal is the same, visually it groups to 3 digits each... but once it goes on to the wire it really doesn't matter what you wrote. That's just a visual representation.
September 7, 20169 yr Of course our friends at Victron with their Hex protocol really aren't doing people any favours. The Victron Hex protocol is essentially an ascii-encoded Hex protocol. You literally convert the hex to its ascii representation and send that instead. That means that the visual representation matters when talking to Victron VE-Direct. Doesn't matter on the MK2 protocol though, also doesn't matter to the Axpert. That's a weird thing they did for VE-Direct... I suppose it makes it simpler for beginners, but it initially confused the crap out of me. Side note... ignore if won't help with your present problem.
September 7, 20169 yr Author 14 minutes ago, plonkster said: Also, you can change the timeout in my code from one second to None, eg timeout=None. Then it will never time out and you will have to hit ctrl+C. But then the cheeky iter() code at the end is going to break too, you'll have to do something like: # Instead of this: i = iter(lambda: port.read(1), '') print list(i) # Do this. while True: x = port.read(1) print x Perhaps the one second timeout isn't enough for the inverter to respond. No distinction on the wire. By the time it hits the wire it's all ones and zeroes. Don't be confused, whether you write 0268 (traditionally a leading zero means octal) or 0xB7 or 183 (decimal) the low level stuff don't care. Writing it in HEX makes it group better visually, because two hex digits is exactly 8 bits, writing it in octal is the same, visually it groups to 3 digits each... but once it goes on to the wire it really doesn't matter what you wrote. That's just a visual representation. hmmmm, ok, so it seems to return "something". pi@raspberrypi:~ $ vim plonkster.py ; python plonkster.py /dev/ttyUSB0 QPI 515049beac0a Yup, that's a bunch of empty lines. Copying / pasting it into notepad or anything else didn't reveal any characters. The strace output: select(4, [3], [], [], {10, 0}) = 0 (Timeout) write(1, "\n", 1 ) = 1 select(4, [3], [], [], {10, 0}) = 0 (Timeout) write(1, "\n", 1 ) = 1 select(4, [3], [], [], {10, 0}) = 0 (Timeout) write(1, "\n", 1 ) = 1 select(4, [3], [], [], {10, 0}) = 0 (Timeout) write(1, "\n", 1 ) = 1 select(4, [3], [], [], {10, 0}) = 0 (Timeout) write(1, "\n", 1 ) = 1 select(4, [3], [], [], {10, 0}) = 0 (Timeout) write(1, "\n", 1 ) = 1
September 7, 20169 yr The timeout is still set to 1? The port.read() will wait one second and then return an empty string... which you're printing. If you set timeout=None, it will block indefinitely until something arrives and then print it. Alternatively, go back to the list printing iter() code, and just up the timeout to a few more seconds. Just don't combine the list building iter() code with an indefinite timeout... because that will just hang and never do anything :-) My theory was that the inverter is slow to respond. I think we've proven now that that is not the case. By the looks of it nothing is coming back. Is the baud rate correct? 2400bps?
September 7, 20169 yr Author Just now, plonkster said: The timeout is still set to 1? The port.read() will wait one second and then return an empty string... which you're printing. If you set timeout=None, it will block indefinitely until something arrives and then print it. Alternatively, go back to the list printing iter() code, and just up the timeout to a few more seconds. Just don't combine the list building iter() code with an indefinite timeout... because that will just hang and never do anything :-) My theory was that the inverter is slow to respond. I think we've proven now that that is not the case. By the looks of it nothing is coming back. Is the baud rate correct? 2400bps? Yes, the timeout is / was 1. I changed it to 10 as well - same thing. 30, same thing, it just takes longer to print the empty lines. baud rate is set to 2400, as you had it. Do you have a Pi with you, that you can test this on? Perhaps this simple won't ever work, though I would like to think that's not the case. And I don't have another inverter here that I can test this one, would have to drive out to client's site, with their permissions, at some stage, to see what it does.
September 7, 20169 yr I find it quite interesting that the Victron specialist is helping to read an Axpert device ... Yes, I have offered, but we chose the 'wrong' language.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.