Mnl sg3 pin numbering
Hi there,
Let me fitst introducé myself. I'm Jack Sleuters and I'm new here. I'm an embedded software Engineer and as of april this year the owner of an LWZ303 SOL. I was browsing the internet for monitoring the LWZ using a Linux pc and came across this site. I followed your instructions on how to assemble the required cable and I proved using serial terminals that the cable works. However, the LWZ does not react as specified on the page. I now wonder if I have the correct pinning on the MNL 3SG connector. Could you please indicate in a picture which pin of de connector is pin1?
As I'm also I to software I might be able to co tribute to this project too.
Kind regards,
Jack
Question information
- Language:
- English Edit question
- Status:
- Solved
- Assignee:
- No assignee Edit question
- Solved by:
- Robert Penz
- Solved:
- Last query:
- Last reply:
Revision history for this message
![]() |
#1 |
hmmmm .... my connector hat the PIN numbers written onto it, anyway I changed the picture to show the PIN numbers
http://
Revision history for this message
![]() |
#2 |
Hi Jack, hi Robert,
did you solve the problem with your non-responding-LWZ?
I am just facing the same problem.
I've built the cable with N-Mate-Lok plug, 10m shielded 4 wire cable (too long?) and Sub-D connector but I don't get any reply from my LWZ 303i which is from form 2010 with software Version 4.09 and ipod panel.
Tried the onboard serial port ttyS0 and a USB2RS232 adapter with Prolific chipset at ttyUSB0 and. No sign of life.
Neither with a serial terminal on /dev/ttyS0 9600,8,N,1 sending hexadzimal byte 02 nor with Roberts python tool which I already adapted to my linux system config:
root@server:
Traceback (most recent call last):
File "./protocol.py", line 258, in <module>
main()
File "./protocol.py", line 252, in main
aP = Protocol(
File "./protocol.py", line 113, in __init__
self._version = self.versionQuery()
File "./protocol.py", line 233, in versionQuery
self.
File "./protocol.py", line 135, in _establishConne
raise IOError, "Error: heat pump does not respond - is it connected?"
IOError: Error: heat pump does not respond - is it connected?
root@server:
I also made some pictures of my cable. Did I mix something up?
[URL=http://
[URL=http://
[URL=http://
[URL=http://
[URL=http://
[URL=http://
The last one is the blueprint. X26 should be the one we are connecting to, right?
Best regards,
milamber
Revision history for this message
![]() |
#3 |
hmmm .. .seems to be problem with the newest version of the heatpump firmware ... I need to look into it
Revision history for this message
![]() |
#4 |
Hi Robert,
in the menu "Inbetriebname" the "Terminaladresse" is configured to "01". Don't know whether this has something to say or not.
The connection to the heatpump should be DTE (data terminal equipment) (heatpump) to DTE (PC) so the RX and TX lines must be crossed, right?
If you need any traces from serial communication maybe from windows just tell me which software to use. Moreover I could do some protocol reverse engineering, too, if I had a working tool - no matter if windows or linux. Will ComfortSoft 3.5.0 (http://
Bye,
milamber
Revision history for this message
![]() |
#5 |
I made some progress.
The cable is ok. I had the chance to connect to the heatpump using a notebook with SE software 5.10 under Windows.
The strange thing is: the protocol did not change. The windows software is still sending the same requests and gets the same or similar answers, as the serial monitor reveals.
Nevertheless Jack, me and others are facing the problem that the heatpump does neither answer to your script - nor to a simple 0x02 request via putty (for people trying to send a 0x02 via putty: hold "ALT" and hit "02" subsequently on the Numberblock to generate the 0x02 hex code from your keyboard (works everywhere with every hexcode)).
I did some serial port monitoring with (http://
- putty opening the port, sending 0x02, <receiving no answer>, closing the port
- the SE Software opening the port sending 0x02, getting ack, requesting version, getting version, closing the port.
Here is the result from putty receiving no answer even after waiting for a longer time:
----------------
Port geöffnet durch Vorgang "putty.exe" (PID: 2752)
Request: 08.02.2011 08:02:38.49964 (+32.0625 seconds)
02 .
Port geschlossen
Here is the result of the SE Soft:
----------------
Port geöffnet durch Vorgang "LWZ303_2007.exe" (PID: 5724)
02 .
Answer: 08.02.2011 08:04:01.29664 (+0.0000 seconds)
10 .
Request: 08.02.2011 08:04:01.31264 (+0.0156 seconds)
01 00 FE FD 10 03 ..þý..
Answer: 08.02.2011 08:04:01.34364 (+0.0156 seconds)
10 02 ..
Request: 08.02.2011 08:04:01.34364 (+0.0000 seconds)
10 .
Answer: 08.02.2011 08:04:01.34364 (+0.0000 seconds)
01 00 98 FD 01 99 10 03 ..?ý.?..
Request: 08.02.2011 08:04:01.35964 (+0.0156 seconds)
10 .
Port geschlossen
----------------
Maybe there is some tricky thing with the initialization and usage of the port - the SE Soft does significantly more things.
This is what putty does:
----------------
#,Function,
0,IRP_MJ_
1,IRP_MJ_
2,IRP_MJ_
3,IRP_MJ_
4,IRP_MJ_
5,IRP_MJ_
6,IRP_MJ_
7,IRP_MJ_
8,IRP_MJ_
9,IRP_MJ_
10,IRP_
11,IRP_
12,IRP_
13,IRP_
14,IRP_
15,IRP_
16,IRP_
17,IRP_
18,IRP_
19,IRP_
20,IRP_
21,IRP_
22,IRP_
23,IRP_
24,IRP_
25,IRP_
26,IRP_
27,IRP_
28,IRP_
29,IRP_
30,IRP_
31,IRP_
32,IRP_
33, IRP_MJ_
34, IRP_MJ_
35,IRP_
36,IRP_
37,IRP_
This is what SE does:
----------------
#,Function,
38,IRP_
39,IRP_
40,IRP_
41,IRP_
42,IRP_
43,IRP_
44,IRP_
45,IRP_
46,IRP_
47,IRP_
48,IRP_
49,IRP_
50,IRP_
51,IRP_
52,IRP_
53,IRP_
54,IRP_
55,IRP_
56,IRP_
57,IRP_
58,IRP_
59,IRP_
60,IRP_
61,IRP_
62,IRP_
63,IRP_
64,IRP_
65,IRP_
66,IRP_
67,IRP_
68,IRP_
69,IRP_
70,IRP_
71,IRP_
72,IRP_
73,IRP_
74,IRP_
75,IRP_
76,IRP_
77,IRP_
78,IRP_
79,IRP_
80,IRP_
81,IRP_
82,IRP_
83,IRP_
84,IRP_
85,IRP_
86,IRP_
87,IRP_
88,IRP_
89,IRP_
90,IRP_
91,IRP_
92,IRP_
93,IRP_
94,IRP_
95,IRP_
96,IRP_
97,IRP_
98,IRP_
99,IRP_
100,IRP_
101,IRP_
102,IRP_
103,IRP_
104,IRP_
105,IRP_
106,IRP_
107,IRP_
108,IRP_
109,IRP_
110,IRP_
111,IRP_
112,IRP_
113, IRP_MJ_
114, IRP_MJ_
115, IRP_MJ_
116, IRP_MJ_
117, IRP_MJ_
118, IRP_MJ_
119, IRP_MJ_
120, IRP_MJ_
121, IRP_MJ_
122, IRP_MJ_
123, IRP_MJ_
124, IRP_MJ_
125, IRP_MJ_
126, IRP_MJ_
127, IRP_MJ_
128, IRP_MJ_
129, IRP_MJ_
130, IRP_MJ_
131, IRP_MJ_
132, IRP_MJ_
133, IRP_MJ_
134, IRP_MJ_
135, IRP_MJ_
136, IRP_MJ_
137, IRP_MJ_
138, IRP_MJ_
139, IRP_MJ_
140, IRP_MJ_
141, IRP_MJ_
142, IRP_MJ_
143, IRP_MJ_
144, IRP_MJ_
145, IRP_MJ_
146, IRP_MJ_
147, IRP_MJ_
148, IRP_MJ_
149, IRP_MJ_
150, IRP_MJ_
151, IRP_MJ_
152, IRP_MJ_
153, IRP_MJ_
154, IRP_MJ_
155, IRP_MJ_
156, IRP_MJ_
157, IRP_MJ_
158, IRP_MJ_
159, IRP_MJ_
160, IRP_MJ_
161, IRP_MJ_
162, IRP_MJ_
163, IRP_MJ_
164, IRP_MJ_
165, IRP_MJ_
166, IRP_MJ_
167, IRP_MJ_
168, IRP_MJ_
169, IRP_MJ_
170, IRP_MJ_
171, IRP_MJ_
172, IRP_MJ_
173, IRP_MJ_
174, IRP_MJ_
175, IRP_MJ_
176, IRP_MJ_
177, IRP_MJ_
178, IRP_MJ_
179, IRP_MJ_
180, IRP_MJ_
181, IRP_MJ_
182, IRP_MJ_
183, IRP_MJ_
184, IRP_MJ_
185, IRP_MJ_
186, IRP_MJ_
187, IRP_MJ_
188, IRP_MJ_
189, IRP_MJ_
190, IRP_MJ_
191, IRP_MJ_
192, IRP_MJ_
193, IRP_MJ_
194, IRP_MJ_
195, IRP_MJ_
196, IRP_MJ_
197, IRP_MJ_
198, IRP_MJ_
199, IRP_MJ_
200, IRP_MJ_
201, IRP_MJ_
202, IRP_MJ_
203, IRP_MJ_
204, IRP_MJ_
205, IRP_MJ_
206, IRP_MJ_
207, IRP_MJ_
208, IRP_MJ_
209, IRP_MJ_
210, IRP_MJ_
211, IRP_MJ_
212, IRP_MJ_
213, IRP_MJ_
214, IRP_MJ_
215, IRP_MJ_
216, IRP_MJ_
217, IRP_MJ_
218, IRP_MJ_
219, IRP_MJ_
220, IRP_MJ_
221, IRP_MJ_
222, IRP_MJ_
223, IRP_MJ_
224, IRP_MJ_
225, IRP_MJ_
226, IRP_MJ_
227, IRP_MJ_
228, IRP_MJ_
229, IRP_MJ_
230, IRP_MJ_
231, IRP_MJ_
232, IRP_MJ_
233, IRP_MJ_
234, IRP_MJ_
235, IRP_MJ_
236, IRP_MJ_
237, IRP_MJ_
238, IRP_MJ_
239, IRP_MJ_
240, IRP_MJ_
241, IRP_MJ_
242, IRP_MJ_
243, IRP_MJ_
244, IRP_MJ_
245, IRP_MJ_
246, IRP_MJ_
247, IRP_MJ_
248, IRP_MJ_
249,IRP_
250,IRP_
251,IRP_
252,IRP_
253,IRP_
254,IRP_
255,IRP_
256,IRP_
257,IRP_
258,IRP_
259,IRP_
260,IRP_
261,IRP_
262,IRP_
263,IRP_
264,IRP_
265,IRP_
266,IRP_
267,IRP_
268,IRP_
269,IRP_
270,IRP_
271,IRP_
272,IRP_
273,IRP_
274,IRP_
275,IRP_
276,IRP_
277,IRP_
278,IRP_
279,IRP_
280,IRP_
281,IRP_
282,IRP_
283,IRP_
284,IRP_
285,IRP_
286,IRP_
287,IRP_
288,IRP_
289,IRP_
290,IRP_
291,IRP_
292,IRP_
293,IRP_
294,IRP_
295,IRP_
296,IRP_
297,IRP_
298,IRP_
299,IRP_
300,IRP_
301,IRP_
302,IRP_
303,IRP_
304,IRP_
305,IRP_
306,IRP_
307,IRP_
308,IRP_
309, IRP_MJ_
310, IRP_MJ_
311, IRP_MJ_
312, IRP_MJ_
313, IRP_MJ_
314, IRP_MJ_
315, IRP_MJ_
316, IRP_MJ_
317, IRP_MJ_
318, IRP_MJ_
319, IRP_MJ_
320, IRP_MJ_
321, IRP_MJ_
322, IRP_MJ_
323, IRP_MJ_
324, IRP_MJ_
325, IRP_MJ_
326, IRP_MJ_
327, IRP_MJ_
328, IRP_MJ_
329, IRP_MJ_
330, IRP_MJ_
331, IRP_MJ_
332, IRP_MJ_
333, IRP_MJ_
334, IRP_MJ_
335, IRP_MJ_
336, IRP_MJ_
337, IRP_MJ_
338, IRP_MJ_
339, IRP_MJ_
340, IRP_MJ_
341, IRP_MJ_
342, IRP_MJ_
343, IRP_MJ_
344, IRP_MJ_
345, IRP_MJ_
346, IRP_MJ_
347, IRP_MJ_
348, IRP_MJ_
349, IRP_MJ_
350, IRP_MJ_
351, IRP_MJ_
352, IRP_MJ_
353, IRP_MJ_
354, IRP_MJ_
355, IRP_MJ_
356, IRP_MJ_
357, IRP_MJ_
358, IRP_MJ_
359, IRP_MJ_
360, IRP_MJ_
361, IRP_MJ_
362, IRP_MJ_
363, IRP_MJ_
364, IRP_MJ_
365, IRP_MJ_
366, IRP_MJ_
367, IRP_MJ_
368, IRP_MJ_
369, IRP_MJ_
370, IRP_MJ_
371, IRP_MJ_
372, IRP_MJ_
373, IRP_MJ_
374, IRP_MJ_
375, IRP_MJ_
376, IRP_MJ_
377, IRP_MJ_
378, IRP_MJ_
379, IRP_MJ_
380, IRP_MJ_
381, IRP_MJ_
382, IRP_MJ_
383, IRP_MJ_
384, IRP_MJ_
385, IRP_MJ_
386, IRP_MJ_
387, IRP_MJ_
388, IRP_MJ_
389, IRP_MJ_
390, IRP_MJ_
391, IRP_MJ_
392, IRP_MJ_
393, IRP_MJ_
394, IRP_MJ_
395, IRP_MJ_
396, IRP_MJ_
397, IRP_MJ_
398, IRP_MJ_
399, IRP_MJ_
400, IRP_MJ_
401, IRP_MJ_
402, IRP_MJ_
403, IRP_MJ_
404, IRP_MJ_
405, IRP_MJ_
406, IRP_MJ_
407, IRP_MJ_
408, IRP_MJ_
409, IRP_MJ_
410, IRP_MJ_
411, IRP_MJ_
412, IRP_MJ_
413, IRP_MJ_
414, IRP_MJ_
415, IRP_MJ_
416, IRP_MJ_
417, IRP_MJ_
418, IRP_MJ_
419, IRP_MJ_
420, IRP_MJ_
421, IRP_MJ_
422, IRP_MJ_
423, IRP_MJ_
424, IRP_MJ_
425, IRP_MJ_
426, IRP_MJ_
427, IRP_MJ_
428, IRP_MJ_
429,IRP_
430,IRP_
431,IRP_
----------------
Somewhere there must be the magic.
Here are the most obvious differences from the logs below:
#,Function,
Putty:
30,IRP_
SE Software:
40,IRP_
108,IRP_
110,IRP_
112,IRP_
The SE Software
- uses a queue (IOCTL_
typedef struct _SERIAL_QUEUE_SIZE {
ULONG InSize;
ULONG OutSize;
} SERIAL_
-> SE uses in and out queue sizes of:
00 10 00 00 = 0x 00 00 10 00 = 4096 Bytes
00 10 00 00 = 0x 00 00 10 00 = 4096 Bytes
- waits on a special event using a wait mask (IOCTL_
The IOCTL_SERIAL_
#define SERIAL_EV_RXCHAR 0x0001 // Any Character received =0b 0000000000001
#define SERIAL_EV_RXFLAG 0x0002 // Received certain character =0b 0000000000010
#define SERIAL_EV_TXEMPTY 0x0004 // Transmitt Queue Empty =0b 0000000000100
#define SERIAL_EV_CTS 0x0008 // CTS changed state =0b 0000000001000
#define SERIAL_EV_DSR 0x0010 // DSR changed state =0b 0000000010000
#define SERIAL_EV_RLSD 0x0020 // RLSD changed state =0b 0000000100000
#define SERIAL_EV_BREAK 0x0040 // BREAK received =0b 0000001000000
#define SERIAL_EV_ERR 0x0080 // Line status error occurred =0b 0000010000000
#define SERIAL_EV_RING 0x0100 // Ring signal detected =0b 0000100000000
#define SERIAL_EV_PERR 0x0200 // Printer error occured =0b 0001000000000
#define SERIAL_EV_RX80FULL 0x0400 // Receive buffer is 80 percent full =0b 0010000000000
#define SERIAL_EV_EVENT1 0x0800 // Provider specific event 1 =0b 0100000000000
#define SERIAL_EV_EVENT2 0x1000 // Provider specific event 2 =0b 1000000000000
-> SE uses IOCTL_SERIAL_
F9 01 00 00 = 00 00 01 F9 = 0b 111 111 00 1 = RXCHAR,
which makes sense for modem communication.
On our 3-wire-connector, CTS, DSR, RLSD, RING are not necessary
-> SE waits on mask: IOCTL_SERIAL_
- has different timeout values
typedef struct _SERIAL_TIMEOUTS {
ULONG ReadIntervalTim
ULONG ReadTotalTimeou
ULONG ReadTotalTimeou
ULONG WriteTotalTimeo
ULONG WriteTotalTimeo
} SERIAL_
-> SE uses timeout values:
FF FF FF FF = 0x FF FF FF FF = 4294967295
00 00 00 00 = 0x 00 00 00 00 = 0
00 00 00 00 = 0x 00 00 00 00 = 0
00 00 00 00 = 0x 00 00 00 00 = 0
00 00 00 00 = 0x 00 00 00 00 = 0
-> Putty sets timeout values:
01 00 00 00 = 0x 00 00 00 10 = 1
00 00 00 00 = 0x 00 00 00 00 = 0
00 00 00 00 = 0x 00 00 00 00 = 0
00 00 00 00 = 0x 00 00 00 00 = 0
00 00 00 00 = 0x 00 00 00 00 = 0
Here is the IOCTL_SERIAL Doku:
http://
nttser.h:
http://
Bye,
milamber
Revision history for this message
![]() |
#6 |
can you provide me with the values of following settings the windows software sets at opening the interface. I was not able to see it at your traces. Thx.
# baudrate – Baud rate such as 9600 or 115200 etc.
# bytesize – Number of data bits. Possible values
# parity – Enable parity checking.
# stopbits – Number of stop bits.
# xonxoff – Enable software flow control.
# rtscts – Enable hardware (RTS/CTS) flow control.
# dsrdtr – Enable hardware (DSR/DTR) flow control.
Revision history for this message
![]() |
#7 |
It seems to me that the SE software uses a baudrate of 57600 instead of 9600! If I interpret the log files of Milamber correctly then on line 18 the baud rate is set to 0x80 0x25 (which I interpret as 0x2580 = 9600 decimal). The SE software sets the baud rate on lines 90, 129, 161, 193, 225 to 0x00 0xE1 (which I interpret as 0xE100 = 57600 decimal).
Milamber, could you try using a baud rate of 57600 in Robert scripts?
Good luck,
Jack
Revision history for this message
![]() |
#8 |
Some more investigation of the SE log file:
SERIAL_LINE_CONTROL
StopBits=0
Parity=0
Wordlength=8
SERIAL_HANDFLOW
ULONG ControlHandShake = 0x00000001 (SERIAL_
ULONG FlowReplace = 0x00000000
LONG XonLimit = 0x00000800 (2048)
Long XoffLimit = 0x00000200 (512)
SERIAL_CHARS
UCHAR EofChar = 0x00
UCHAR ErrorChar = 0x00
UCHAR BreakChar = 0x00
UCHAR EventChar = 0x00
UCHAR XonChar = 0x11
UCHAR XoffChar = 0x13
Is XonXoff used?
Hope this helps!
Regards,
Jack
Revision history for this message
![]() |
#9 |
There's some light at the end of the tunnel!
After setting my serial terminal to 57600,8,N,1 under linux I got the 0x10 answer on my 0x02, Jack :-)
Still no reply to the version request 01 00 FE FD 10 03.
Working on it...
Revision history for this message
![]() |
#10 |
Where can the baud rate be configured in Robert's script?
Revision history for this message
![]() |
#11 |
I'll prepare my script to handle both headpump types and baud rates and get back to you with an updated version which where the baud rate is changeable.
Revision history for this message
![]() |
#12 |
According to my investigation, the following line control attributes are used by the SE software:
SERIAL_LINE_CONTROL
StopBits=0
Parity=0
Wordlength=8
So the serial port should be setup as 57600, 8, N, 0
No parity, no stop bits. Did you try this too Milamber?
Revision history for this message
![]() |
#13 |
Apparently I have a problem with the StopBit Setting.
gtkterm does support sending hex codes via Interface, but doesn't support StopBits=0
hterm does support sending hex codes via Interface, but doesn't support StopBits=0
picocom & minicom don't support StopBits=0
putty does support StopBits=0 but I can't enter hex codes via NX remote from my linux server next to the LWZ. Did the ALT+02 directly from a windows putty from a notebook next to the LWZ.
Any other terminals?
Revision history for this message
![]() |
#14 |
I now also know that my cable does work! Thanks
Revision history for this message
![]() |
#15 |
Putty under Windows also says that only 1, 1.5 or 2 StopBits are allowed.
Revision history for this message
![]() |
#16 |
I don't think that stopbits = 0 is valid.
Revision history for this message
![]() |
#17 |
I think you're right, maybe the stopbit value should be interpreted differently:
0 = 1 stopbit
1 = 1.5 stopbits
2 = 2 stopbits
Revision history for this message
![]() |
#18 |
I've updated the trunk version, now there is a option in heatpump.ini called newStyleServial
Starting ...
Heatpump reports Version 4.39
=========
No configuration available for this software version of the heat pump.
---------
Traceback (most recent call last):
File "./heatpumpMoni
p = protocol.
File "/root/
self._config = self._protocolV
File "/root/
raise ValueError, "No configuration available for this software version of the heat pump."
ValueError: No configuration available for this software version of the heat pump.
=========
There is no protocol config for that version at the moment but the communication itself is working.
Revision history for this message
![]() |
#19 |
That sounds good! How do I get the latest trunk version?
Revision history for this message
![]() |
#20 |
Revision history for this message
![]() |
#21 |
Hi Robert,
It seems to work! I get the following output executing python protocol.py:
Heatpump reports Version 4.19
Traceback (most recent call last):
File "protocol.py", line 264, in <module>
main()
File "protocol.py", line 258, in main
aP = Protocol(
File "protocol.py", line 117, in __init__
self._config = self._protocolV
File "/home/
raise ValueError, "No configuration available for this software version of the heat pump."
ValueError: No configuration available for this software version of the heat pump.
Revision history for this message
![]() |
#22 |
I copied protocolVersion 4.39 to protocolVersion 4.19 and in there changed the version to 4.19.
I changed the file locations of logFile pidFile, graph location etc. to my likings in heatpumpMonitor
I was able to get the heatpumpMonitor daemon running and graphs are being generated.
I need to look some more into the setup details but the change by Robert in the trunk version of the software does solve the communication problem!
Thanks to all that helped getting the Monitor to work!
Kind regards,
Jack
Revision history for this message
![]() |
#23 |
Looks good!
Just copied one of the existing protocols to 4.09.
Parameter mapping in the ini has to be adapted. I guess Jack and me are going to investigate that. I'll go on pasting my results here.
By now I already have this nice output of protocol.py:
Heatpump reports Version 4.09
Using protocol definition from Beier Andreas <email address hidden> (Tested currently only on a LWZ 303i, send me a line if it works on others too.)
Traceback (most recent call last):
File "./protocol.py", line 264, in <module>
main()
File "./protocol.py", line 260, in main
print aP.query()
File "./protocol.py", line 250, in query
result.
File "./protocol.py", line 226, in _getValues
s = self._get(
File "./protocol.py", line 200, in _get
raise IOError, "Error: the received %s response has an invalid length (%d instead of %d)" % (queryName, len(s) - 2, queryResponseLe
IOError: Error: the received ActualValues response has an invalid length (53 instead of 41)
Revision history for this message
![]() |
#24 |
Here are the changes for Version 4.09 based on 2.06 ini:
Just checkd the Actual Values section.
Very annoying, that I could not find the vent_speed_actual !
The value at pos -2 (3rd byte in the header) is changing between:
1E = 30
1E = 30
1D = 29
1F = 31
21 = 33
1F = 31
1F = 31
20 = 32
1F = 31
20 = 32
Maybe that's the actual fan speed? Have to check that by changing the ventilation ...
For now I have:
[Global]
versions = 4.09
[ActualValues]
responseLength = 53
# name pos type size fixedDecimals
# -------
value01 = flow_temp 4 fixedPoint 2 1
value02 = return_temp 6 fixedPoint 2 1
value03 = hot_gas_temp 8 fixedPoint 2 1
value04 = dhw_temp 10 fixedPoint 2 1
value05 = flow_temp_hc2 12 fixedPoint 2 1
value07 = evaporator_temp 16 fixedPoint 2 1
value08 = condenser_temp 18 fixedPoint 2 1
value12 = extr_speed_actual 30 fixedPoint 1 0
#value13 = vent_speed_actual 27 fixedPoint 1 0
value14 = expel_speed_actual 32 fixedPoint 1 0
value15 = outside_temp 2 fixedPoint 2 1
#value16 = outside_
value17 = compressor_temp 14 fixedPoint 2 1
Revision history for this message
![]() |
#25 |
On LWZ 303i Firmware 4.09 with iPOD Control
Revision history for this message
![]() |
#26 |
This is the contents of the Firmware 4.19 on a SE LWZ303 SOL:
value01 = collector_temp 0 fixedPoint 2 1
value02 = dont_know_1 2 fixedPoint 2 1
value03 = flow_temp 4 fixedPoint 2 1
value04 = return_temp 6 fixedPoint 2 1
value05 = hot_gas_temp 8 fixedPoint 2 1
value06 = dhw_temp 10 fixedPoint 2 1
value07 = flow_temp_hc2 12 fixedPoint 2 1
value08 = return_temp_hc2 14 fixedPoint 2 1
value09 = evaporator_temp 16 fixedPoint 2 1
value10 = condenser_temp 18 fixedPoint 2 1
value11 = dont_know_2_ausgang 20 fixedPoint 2 0
value12 = dont_know_3_status 22 fixedPoint 1 0
value13 = extr_speed_set 23 fixedPoint 2 1
value14 = vent_speed_set 25 fixedPoint 2 1
value15 = expel_speed_set 27 fixedPoint 2 1
value16 = extr_speed_actual 29 fixedPoint 2 0
value17 = vent_speed_actual 31 fixedPoint 2 0
value18 = expel_speed_actual 33 fixedPoint 2 0
value19 = outside_temp 35 fixedPoint 2 1
value20 = rel_humidity 37 fixedPoint 2 1
value21 = dew_point_temp 39 fixedPoint 2 1
value22 = p_nd 41 fixedPoint 2 2
value23 = p_hd 43 fixedPoint 2 2
Revision history for this message
![]() |
#27 |
At the moment I am often getting outages of roundabout 15 minuts in the monitoring.
The log shows that sometimes (timestamps would be a great thing for the log) the Actualvalues request does not work every time. Is this a typical too long cable error? My 10m cable seem to be long for 57600 according to http://
=========
Error: heat pump does not understand ActualValues request
---------
Traceback (most recent call last):
File "./heatpumpMoni
values = p.query()
File "/home/
result.
File "/home/
s = self._get(
File "/home/
raise IOError, "Error: heat pump does not understand %s request" % queryName
IOError: Error: heat pump does not understand ActualValues request
=========
-------------
Error: [heatpumpMonitor] Query error theshhold exceeded
Error details The number of queries which failed in a row exceeded the defined
threshold. Is the heatpump still connected and running? It is also possible that the software
of the heat pumpt crashed or not that stable. Take a look at it. An other possibility is that
the connection is not good and you get a lot of CRC errors. In all cases take a lock at the
logfile.
-------------
debug: |
=========
Error: could not be set again into receiving mode (ActualValues)
---------
Traceback (most recent call last):
File "./heatpumpMoni
values = p.query()
File "/home/
result.
File "/home/
s = self._get(
File "/home/
raise IOError, "Error: could not be set again into receiving mode (%s)" % queryName
IOError: Error: could not be set again into receiving mode (ActualValues)
=========
Revision history for this message
![]() |
#28 |
Also happens nearly every second time I start protocol.py from hand.
Will try to shorten the cable tonight from 10 to 6m. COM port is a true COM port - no USB2SERIAL adapter, which often causes instability, too.
Revision history for this message
![]() |
#29 |
added a timestamp for the error log to the trunk version.
ps: maybe it is possible to reduce the bps for the connection somehow (an option with the original software?)
Revision history for this message
![]() |
#30 |
Shortened the cable from 10m to 5m - absolutely no improvement.
The requests don't work in about 30% of my tries.
Revision history for this message
![]() |
#31 |
I think someone had the same problem with an older firmware version ..... If you run the original software, the problem does not happen? what is the difference in the communication?
Revision history for this message
![]() |
#32 |
The SE Software has no problems even when reading the LWZ internal data log with >20k entries.
The behaviour of the SE Software is visible in my post from 2011-02-08. Maybe it is the use of wait masks.
Jack, do you have no problems like that?
Revision history for this message
![]() |
#33 |
Hi,
I don't have any of the problems you report Milamber. I use a cat5 network cable and a usb to serial converter for the connection cable with the heatpump. After Robert made the adjustments for the higher baudrate, the heatpumpmonitor python scripts work like a charm at my place (I added monitoring the solar collector temperature too).
If I understand correctly, you shortened the cable and afterwards, the SE software still works correctly, but the heatpump scripts don't work all the time. When you get in an error situation does the software stop? If so, could you modify the code that it will retry to get the values after an error? Does it fail all the time afterwards?
Revision history for this message
![]() |
#34 |
Lets close this question and make a new one specific to this problem with the important info copied from this. Maybe someone else has the same problem and we can look at the similarities. I'll also take a look at the traces as soon as I've some time for it.
Revision history for this message
![]() |
#36 |
Here is the config file for version 4.09 of the LWZ 303i (nonSOL). It can be added to the project.
All values in ActualValues, HeatingValues, OperationalState and FaultMemory were adapted.
Values 02-05 in "HeatingValues" are uncommented, because they are duplicates to ActualValues or unknown.
[Global]
# if this file is valid for more than one version add the versions seperated by space
versions = 4.09
# the name and email address of the author of this file
author = milamber (based on 4.38 Robert Penz <email address hidden> and 2.06 Beier Andreas)
# anything that would be good to know for the readers of this file
comment = v0.1 Created for LWZ 303i V4.09 (iPod control) - 57600 Baud
# following querys should be send to the heat pump in the given order (seperated by space)
# all queries are performed before returning to e.g. the storage and render part. This allows
# the authors of these ini files to choose which query the use to get a certian value.
# You need to provide an ini file section for each list entry.
queries = ActualValues HeatingValues OperationalState FaultMemory
# This version of the heat pump software is somehow weird, it sends "\x2b\x18" if it means only "\x2b",
# this would break the parsing so we replace it back.
globalReplaceString = \x2b\x18 \x2b
[ActualValues]
# write something informative
comment = primary source of values
# the actual request send to the heat pump
request = \xfb
# the required length of the returned string, if the response has a different size it is a
# sign that something does not fit
responseLength = 53
# list the values which will be returned in this query and should be parsed
# the values will be extracted in the provided order
# These ini file entries are in it self seperated by space or tab and have parts have following meanings
# 1. name of the value, it needs to fit to one of the names in heatpumpMonitor to get used (e.g. stored in the rrd)
# 2. position of the first byte of the value in the response (first byte in a response has position 0 and not 1)
# 4. type of the value, currently only fixedPoint is supported, but which works also for integers
# 5. size of the value (= how many bytes belong to it)
# 6. number of fixed decimals digits, use 0 to get an integer
# name pos type size fixedDecimals
# -------
value01 = flow_temp 4 fixedPoint 2 1
value02 = return_temp 6 fixedPoint 2 1
value03 = hot_gas_temp 8 fixedPoint 2 1
value04 = dhw_temp 10 fixedPoint 2 1
value05 = flow_temp_hc2 12 fixedPoint 2 1
value07 = evaporator_temp 16 fixedPoint 2 1
value08 = condenser_temp 18 fixedPoint 2 1
value12 = extr_speed_actual 30 fixedPoint 1 0
value14 = expel_speed_actual 32 fixedPoint 1 0
value15 = outside_temp 2 fixedPoint 2 1
value17 = compressor_temp 14 fixedPoint 2 1
[HeatingValues]
comment = the heating values
request = \xf4
responseLength = 39
# name pos type size fixedDecimals
# -------
value01 = inside_temp 32 fixedPoint 2 1
#value02 = return_temp 4 fixedPoint 2 1
#value03 = flow_temp 8 fixedPoint 2 1
#value04 = unknown_temp 10 fixedPoint 2 1
# at ~27.6°C
#value05 = unknown_temp 12 fixedPoint 2 1
# at ~25.9°C
[CurrentTime]
comment = the current time of the heatpump
request = \xfc
responseLength = 9
value01 = hours 2 fixedPoint 1 0
value02 = minutes 3 fixedPoint 1 0
value03 = seconds 4 fixedPoint 1 0
value04 = year 5 fixedPoint 1 0
value05 = month 7 fixedPoint 1 0
value06 = day 8 fixedPoint 1 0
[OperationalState]
comment = how many hours a part of the heat pump was running sofar
request = \x09
# the required length of the returned string, if the response has a different size it is a
# sign that something does not fit
responseLength = 10
# name pos type size fixedDecimals/
# -------
value01 = compressor_heating 0 fixedPoint 2 0
value02 = compressor_cooling 2 fixedPoint 2 0
value03 = compressor_dhw 4 fixedPoint 2 0
value04 = booster_dhw 6 fixedPoint 2 0
value05 = booster_heating 8 fixedPoint 2 0
[FaultMemory]
comment = the ten last errors
request = \xd1
# the required length of the returned string, if the response has a different size it is a
# sign that something does not fit
responseLength = 62
# name pos type size fixedDecimals/
# -------
value01 = number_of_faults 0 fixedPoint 1 0
value02 = fault01code 2 fixedPoint 1 0
value03 = fault01time 4 DateTime 2 :
value04 = fault01date 6 DateTime 2 .
value05 = fault02code 8 fixedPoint 1 0
value06 = fault02time 10 DateTime 2 :
value07 = fault02date 12 DateTime 2 .
value08 = fault03code 14 fixedPoint 1 0
value09 = fault03time 16 DateTime 2 :
value10 = fault03date 18 DateTime 2 .
value11 = fault04code 20 fixedPoint 1 0
value12 = fault04time 22 DateTime 2 :
value13 = fault04date 24 DateTime 2 .
value14 = fault05code 26 fixedPoint 1 0
value15 = fault05time 28 DateTime 2 :
value16 = fault05date 30 DateTime 2 .
value17 = fault06code 32 fixedPoint 1 0
value18 = fault06time 34 DateTime 2 :
value19 = fault06date 36 DateTime 2 .
value20 = fault07code 38 fixedPoint 1 0
value21 = fault07time 40 DateTime 2 :
value22 = fault07date 42 DateTime 2 .
value23 = fault08code 44 fixedPoint 1 0
value24 = fault08time 46 DateTime 2 :
value25 = fault08date 48 DateTime 2 .
value26 = fault09code 50 fixedPoint 1 0
value27 = fault09time 52 DateTime 2 :
value28 = fault09date 54 DateTime 2 .
value29 = fault10code 56 fixedPoint 1 0
value30 = fault10time 58 DateTime 2 :
value31 = fault10date 60 DateTime 2 .
Revision history for this message
![]() |
#37 |
Did a quick & dirty fix for my problem by closing and reestablishing the connection for every failed query. Works very good so far. Here is the hack:
def _get(self, queryName, queryRequest, queryResponseLe
""" internal method which does the real quering - provide it with a dict
of the query protocol and it will handle the rest
"""
while True:
if not self._ser:
# request the data
s = self._ser.read(2)
if s == ESCAPE + STARTCOMMUNICATION:
s = self._ser.read(1)
print "Error: heat pump does not understand %s request." % queryName
## Instead of:
# if not self._ser:
# raise IOError, "Error: serial connection not open"
# if s != ESCAPE + STARTCOMMUNICATION:
# printHex(s)
# raise IOError, "Error: heat pump does not understand %s request." % queryName
## Output looks like this:
$ ./protocol.py
Heatpump reports Version 4.09
Using protocol definition from milamber (based on 4.38 Robert Penz <email address hidden> and 2.06 Beier Andreas) (v0.1 Created for LWZ 303i V4.09 (iPod control) - 57600 Baud)
debug: | 0: fd a8 00 18 | 4: 01 4a 01 31 | 8: 03 5f 01 b1 | 12: fd a8 fd a8 | 16: ff aa 01 49 | 20: 20 08 11 02 | 24: d0 02 d0 02 | 28: 58 00 1b 00 | 32: 1e 00 10 00 | 36: 17 00 00 00 | 40: 00 01 3b 05 | 44: 60 40 6b 61 | 48: 13 3f 8f 89 | 52: 61 |
debug: | 0: 15 |
Error: heat pump does not understand HeatingValues request.
debug: | 0: 00 19 ff 41 | 4: 01 31 ff e9 | 8: 01 4a 01 43 | 12: 01 38 01 00 | 16: 01 01 20 08 | 20: 00 64 01 00 | 24: 00 00 00 d2 | 28: 00 00 16 00 | 32: 00 d2 02 01 | 36: 01 16 00 |
debug: | 0: 04 21 00 00 | 4: 01 5e 00 1b | 8: 01 f8 |
debug: |
Error: heat pump does not understand FaultMemory request.
debug: |
Error: heat pump does not understand FaultMemory request.
debug: | 0: 00 00 00 00 | 4: 00 00 00 00 | 8: 00 00 00 00 | 12: 00 00 00 00 | 16: 00 00 00 00 | 20: 00 00 00 00 | 24: 00 00 00 00 | 28: 00 00 00 00 | 32: 00 00 00 00 | 36: 00 00 00 00 | 40: 00 00 00 00 | 44: 00 00 00 00 | 48: 00 00 00 00 | 52: 00 00 00 00 | 56: 00 00 00 00 | 60: 00 00 |
{'fault10date': '00.00', 'fault07time': '00:00', 'fault08code': 0, 'fault06code': 0, 'number_of_faults': 0, 'fault05time': '00:00', 'compressor_
Well, now I miss the cutted additional 5m which let me hide the cable between LWZ and server ;)
Revision history for this message
![]() |
#38 |
@milamber (milamber-
Hello,
is it possible to get the SW SE 5.10 or higher.
I have a WP with Firmware 4.19 an need minimum 5.10 or higher.
It would very kind of you if it is possible.
My e-mail
markusdattel <at> qip <dot> ru
Thanks
Markus