Hi, i've noticed that values < 65 will not be written correctly .. after some investigation i found out, that the value will be add to the previous byte:
if (total_length == 3) {
word += parseInt(isFinite(value.data) ? value.data : value.data[0]);
this.UInt16BE(word);
btw, I've comitted to master some changes related to issue #29 (which is of similar nature) a week ago, are you able to do a git pull to fetch the latest code and retry?
I have the same problem. The debug-log looks like this:
First I set the dimmer to level 70. This seems to work:
2017-04-02 07:51:41.167 (sendTunnReq): Sending TUNNELING_REQUEST_L_Data.req from port 55972 to [object Object] ==> {"header_length":6,"protocol_version":16,"service_type":1056,"total_length":22,"hpai":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"tunn":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"tunnstate":{"channel_id":77,"tunnel_endpoint":"192.168.1.17:3671","seqnum":105},"cemi":{"msgcode":17,"ctrl":{"frameType":1,"reserved":0,"repeat":1,"broadcast":1,"priority":3,"acknowledge":1,"confirm":0,"destAddrType":1,"hopCount":5,"extendedFrame":0},"src_addr":"15.15.15","dest_addr":"14/2/129","apdu":{"apci":"GroupValue_Write","tpci":0,"data":{"type":"Buffer","data":[70]}}}}
2017-04-02 07:51:41.167 (sendTunnReq): >>>>>>> seqnum: 105
DimmerOutput F1Livingroom ceiling is 70
2017-04-02 07:51:41.167 (sendTunnReq_waitACK): UDP send: TUNNELING_ACK to {"addrstring":"192.168.1.17","addr":{"octets":[192,168,1,17]},"port":3671}: OK
2017-04-02 07:51:41.167 (sendTunnReq_waitACK): UDP send: TUNNELING_REQUEST_L_Data.req to {"addrstring":"192.168.1.17","addr":{"octets":[192,168,1,17]},"port":3671}: OK
2017-04-02 07:51:41.169 (sendTunnReq_waitACK): Inbound message: {"type":"Buffer","data":[6,16,4,33,0,10,4,77,105,0]}
2017-04-02 07:51:41.169 (sendTunnReq_waitACK): Received TUNNELING_ACK message: {"header_length":6,"protocol_version":16,"service_type":1057,"total_length":10,"tunnstate":{"header_length":4,"channel_id":77,"seqnum":105,"rsvd":0}}
2017-04-02 07:51:41.170 (sendTunnReq_waitACK): ===== datagram 105 acknowledged by IP router
2017-04-02 07:51:41.170 (idle): ...
2017-04-02 07:51:41.170 (idle): Inbound message: {"type":"Buffer","data":[6,16,4,32,0,22,4,77,217,0,46,0,190,192,255,15,114,129,2,0,128,70]}
2017-04-02 07:51:41.170 (idle): Received TUNNELING_REQUEST_L_Data.con message: {"header_length":6,"protocol_version":16,"service_type":1056,"total_length":22,"tunnstate":{"header_length":4,"channel_id":77,"seqnum":217,"rsvd":0},"cemi":{"msgcode":46,"addinfo_length":0,"ctrl":{"frameType":1,"reserved":0,"repeat":1,"broadcast":1,"priority":3,"acknowledge":1,"confirm":0,"destAddrType":1,"hopCount":4,"extendedFrame":0},"src_addr":"15.15.15","dest_addr":"14/2/129","apdu":{"apdu_length":2,"apdu_raw":{"type":"Buffer","data":[0,128,70]},"tpci":0,"apci":"GroupValue_Write","data":{"type":"Buffer","data":[70]}}}}
2017-04-02 07:51:41.170 (idle): 14/2/129: delivery confirmation (L_Data.con) received
2017-04-02 07:51:41.170 (idle): Sending TUNNELING_ACK from port 55972 to [object Object] ==> {"header_length":6,"protocol_version":16,"service_type":1057,"total_length":10,"hpai":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"tunnstate":{"channel_id":77,"tunnel_endpoint":"192.168.1.17:3671","seqnum":217}}
2017-04-02 07:51:41.171 (idle): UDP send: TUNNELING_ACK to {"addrstring":"192.168.1.17","addr":{"octets":[192,168,1,17]},"port":3671}: OK
Then I try to set it to zero. This does not have any effect:
2017-04-02 07:51:42.497 (sendTunnReq): Sending TUNNELING_REQUEST_L_Data.req from port 55972 to [object Object] ==> {"header_length":6,"protocol_version":16,"service_type":1056,"total_length":21,"hpai":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"tunn":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"tunnstate":{"channel_id":77,"tunnel_endpoint":"192.168.1.17:3671","seqnum":106},"cemi":{"msgcode":17,"ctrl":{"frameType":1,"reserved":0,"repeat":1,"broadcast":1,"priority":3,"acknowledge":1,"confirm":0,"destAddrType":1,"hopCount":5,"extendedFrame":0},"src_addr":"15.15.15","dest_addr":"14/2/129","apdu":{"apci":"GroupValue_Write","tpci":0,"data":{"type":"Buffer","data":[0]}}}}
2017-04-02 07:51:42.497 (sendTunnReq): >>>>>>> seqnum: 106
DimmerOutput F1Livingroom ceiling is 0
2017-04-02 07:51:42.506 (sendTunnReq_waitACK): UDP send: TUNNELING_ACK to {"addrstring":"192.168.1.17","addr":{"octets":[192,168,1,17]},"port":3671}: OK
2017-04-02 07:51:42.506 (sendTunnReq_waitACK): UDP send: TUNNELING_REQUEST_L_Data.req to {"addrstring":"192.168.1.17","addr":{"octets":[192,168,1,17]},"port":3671}: OK
2017-04-02 07:51:42.508 (sendTunnReq_waitACK): Inbound message: {"type":"Buffer","data":[6,16,4,33,0,10,4,77,106,0]}
2017-04-02 07:51:42.508 (sendTunnReq_waitACK): Received TUNNELING_ACK message: {"header_length":6,"protocol_version":16,"service_type":1057,"total_length":10,"tunnstate":{"header_length":4,"channel_id":77,"seqnum":106,"rsvd":0}}
2017-04-02 07:51:42.508 (sendTunnReq_waitACK): ===== datagram 106 acknowledged by IP router
2017-04-02 07:51:42.508 (idle): ...
2017-04-02 07:51:42.510 (idle): Inbound message: {"type":"Buffer","data":[6,16,4,32,0,21,4,77,219,0,46,0,190,192,255,15,114,129,1,0,128]}
2017-04-02 07:51:42.511 (idle): Received TUNNELING_REQUEST_L_Data.con message: {"header_length":6,"protocol_version":16,"service_type":1056,"total_length":21,"tunnstate":{"header_length":4,"channel_id":77,"seqnum":219,"rsvd":0},"cemi":{"msgcode":46,"addinfo_length":0,"ctrl":{"frameType":1,"reserved":0,"repeat":1,"broadcast":1,"priority":3,"acknowledge":1,"confirm":0,"destAddrType":1,"hopCount":4,"extendedFrame":0},"src_addr":"15.15.15","dest_addr":"14/2/129","apdu":{"apdu_length":1,"apdu_raw":{"type":"Buffer","data":[0,128]},"tpci":0,"apci":"GroupValue_Write","data":{"type":"Buffer","data":[0]}}}}
2017-04-02 07:51:42.511 (idle): 14/2/129: delivery confirmation (L_Data.con) received
2017-04-02 07:51:42.511 (idle): Sending TUNNELING_ACK from port 55972 to [object Object] ==> {"header_length":6,"protocol_version":16,"service_type":1057,"total_length":10,"hpai":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"tunnstate":{"channel_id":77,"tunnel_endpoint":"192.168.1.17:3671","seqnum":219}}
2017-04-02 07:51:42.511 (idle): UDP send: TUNNELING_ACK to {"addrstring":"192.168.1.17","addr":{"octets":[192,168,1,17]},"port":3671}: OK
I have another project using eibd that I can use to correctly control the dimmer. I will try to find time to dig deeper into the problem.
Apologies, I don't have a dimmer to test against... Will try emulating this in ETS
This is a tcpdump of the following events:
One of the dimmers have group-address 14/2/129.
And some button-presses between them. I don't have time to look into this more tonight. I'll continue my investigation some other day if noone beats me to it.
The pcap-file can be opened in Wireshark, and it seems to decode at least parts of the knx protocol.
Clarification: The pcap-file shows the communication between eibd and my knx gateway and the lights were turned on and off as I expected them to. The commands were sent to eibd from another program that is not using knx.js.
Wireshark show some differences between a working write from my other system and a non-working write from knx.js. The working write uses NPDU length 2, but knx.js uses NPDU-length 1.
Write value 20 with knx.js. Not working.
Write value 20 with other system. Working.
Hi Mattias,
the difference is in the last two bytes. The working example sends: "80 14" (14 is hex for 20) The current implementation sends "94" (i suppose adding 80+14)
So it seems that for DPT5, you should always send the value encoded in a separate byte, even if it is below 63 and would fit into the previous byte.
Changing this code would however not work, since it affects all group_writes:
if (total_length == 3) {
word += parseInt(isFinite(value.data) ? value.data : value.data[0]);
this.UInt16BE(word);
So the question is where should this change be made? Should we always write a Buffer() as separate bytes, i.e. change the code in KnxProtocol.lengths['APDU'] and remove the if-statement
if (value.data.length == 1) {
on line 431?
each dpt definition has the ability to define its own serialisation format, I think we should implement formatAPDU within dpt5.js.
I currently have very few spare time, hope to work on this during the weekend.
I tried implementing formatAPDU for dpt5, but I can't figure out how it is supposed to work. I have added the following test-code to dpt5.js:
exports.formatAPDU = function(value) {
console.log('dpt5', value)
}
This makes the tests fail (of course), but I then wrote the follwing test-code:
const knx = require('knx')
const delay = 0
let connection = new knx.Connection( {
ipAddr: '192.168.1.17',
debug: true,
handlers: {
connected: () => {
console.log('Connected!')
connection.on('event', function (evt, src, dest, value) {
console.log('**** KNX EVENT: %j, src: %j, dest: %j, value: %j',
evt, src, dest, value)
})
let dimmer_control = new knx.Datapoint({ga: '14/2/129', dpt: 'DPT5.001'})
dimmer_control.bind(connection)
dimmer_control.write(100)
// connection.write('14/2/129', new Buffer([20]))
process.on('SIGINT', () => {
console.log('Terminating')
connection.Disconnect()
})
}
}
} )
It fails with
Trace: Fix your code - APDU data payload must be a 6-bit int or an Array/Buffer (1 to 14 bytes), got: 100 (number)
at KnxProtocol.lengths.APDU (/Users/mattias/development/elights-ts/node_modules/knx/src/KnxProtocol.js:444:15)
at knxlen (/Users/mattias/development/elights-ts/node_modules/knx/src/KnxProtocol.js:21:39)
at KnxProtocol.lengths.CEMI (/Users/mattias/development/elights-ts/node_modules/knx/src/KnxProtocol.js:501:21)
at knxlen (/Users/mattias/development/elights-ts/node_modules/knx/src/KnxProtocol.js:21:39)
at KnxProtocol.lengths.KNXNetHeader (/Users/mattias/development/elights-ts/node_modules/knx/src/KnxProtocol.js:622:11)
at knxlen (/Users/mattias/development/elights-ts/node_modules/knx/src/KnxProtocol.js:21:39)
at CustomProtocolWriter.write (/Users/mattias/development/elights-ts/node_modules/knx/src/KnxProtocol.js:561:26)
at CustomProtocolWriter.(anonymous function) [as KNXNetHeader] (/Users/mattias/development/elights-ts/node_modules/binary-protocol/lib/writer.js:20:18)
at fsm.FSM.send (/Users/mattias/development/elights-ts/node_modules/knx/src/Connection.js:173:28)
at fsm._onEnter (/Users/mattias/development/elights-ts/node_modules/knx/src/FSM.js:237:14)
It seems to me like my formatAPDU-code was not even called. I thought my test-program would have sent the data (100) through dpt5.formatAPDU, but it was never even called.
Is there something wrong with the way I am using the datapoints?
Hello all, and thanks for all the information you provided. Just want to say that this is one hell of a tricky issue. - The APDU doesn't carry enough information on its payload size. - To make things worse, there's a vague "camel designedby comittee" requirement that APDU's with 6 bits of payload (ie values < 64) must be marshalled in the 1st byte (so we have header+payload in the same byte!)
I have started refactoring parts of the Knx serialisation, I'll make this a separate branch.
Once again, thanks for all your help.
initial attempt at solving this issue is comitted. Please check out the branch and give it a try: https://bitbucket.org/ekarak/knx.js/branch/bugfix/issue%2330-dpt5-apdu-length#diff
I believe this is now fixed. Please upgrade to version 2.1.0 and reopen the ticket if this is still an issue.
I still can't get DPT5.001 to work. I have upgraded to latest knx.js from master. I have the following test-program:
const knx = require('knx')
const value = 255
let connection = new knx.Connection( {
ipAddr: '192.168.1.17',
debug: true,
handlers: {
connected: () => {
console.log('Connected!')
connection.on('event', function (evt, src, dest, value) {
console.log('**** KNX EVENT: %j, src: %j, dest: %j, value: %j',
evt, src, dest, value)
})
let dimmer_control = new knx.Datapoint({ga: '14/2/129', dpt: 'DPT5.001'})
dimmer_control.bind(connection)
dimmer_control.write(new Buffer([value]))
process.on('SIGINT', () => {
console.log('Terminating')
connection.Disconnect()
})
}
}
} )
It produces the following output:
$ node dimmer-test.js
Loading knx: KNXnet/IP protocol implementation for Node(>=4.x), version: 2.1.0
2017-04-09 14:33:33.490 (uninitialized): initializing connection to 192.168.1.17 (private)
2017-04-09 14:33:33.496 (uninitialized): candidate interface: en0 ({"address":"192.168.1.88","netmask":"255.255.255.0","family":"IPv4","mac":"b8:e8:56:36:7f:62","internal":false})
2017-04-09 14:33:33.496 (uninitialized): candidate interface: en4 ({"address":"192.168.1.82","netmask":"255.255.255.0","family":"IPv4","mac":"0c:4d:e9:a5:47:5c","internal":false})
2017-04-09 14:33:33.497 (uninitialized): IpTunnelingConnection.BindSocket
2017-04-09 14:33:33.507 (uninitialized): tunneling socket bound to {"address":"0.0.0.0","family":"IPv4","port":61370}
2017-04-09 14:33:33.507 (connecting): Connecting to 192.168.1.88...
2017-04-09 14:33:33.511 (connecting): Sending CONNECT_REQUEST ==> {"header_length":6,"protocol_version":16,"service_type":517,"total_length":26,"hpai":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"tunn":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"cri":{"connection_type":4,"knx_layer":2,"unused":0},"connstate":{"state":0}}
2017-04-09 14:33:33.513 (connecting): UDP send OK: CONNECT_REQUEST {"type":"Buffer","data":[6,16,2,5,0,26,8,1,0,0,0,0,0,0,8,1,0,0,0,0,0,0,4,4,2,0]}
2017-04-09 14:33:33.513 (connecting): Inbound message: {"type":"Buffer","data":[6,16,2,6,0,20,103,0,8,1,0,0,0,0,0,0,4,4,0,0]}
2017-04-09 14:33:33.517 (connecting): Received CONNECT_RESPONSE message: {"header_length":6,"protocol_version":16,"service_type":518,"total_length":20,"connstate":{"channel_id":103,"status":0},"hpai":{"header_length":8,"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"cri":{"header_length":4,"connection_type":4,"knx_layer":0,"unused":0}}
2017-04-09 14:33:33.517 (connecting): got connect response
2017-04-09 14:33:33.518 (connecting): Sending CONNECTIONSTATE_REQUEST ==> {"header_length":6,"protocol_version":16,"service_type":519,"total_length":16,"hpai":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"connstate":{"channel_id":103,"state":0}}
2017-04-09 14:33:33.518 (connecting): UDP send OK: CONNECTIONSTATE_REQUEST {"type":"Buffer","data":[6,16,2,7,0,16,103,0,8,1,0,0,0,0,0,0]}
2017-04-09 14:33:33.519 (connecting): Inbound message: {"type":"Buffer","data":[6,16,2,8,0,8,103,0]}
2017-04-09 14:33:33.520 (connecting): Received CONNECTIONSTATE_RESPONSE message: {"header_length":6,"protocol_version":16,"service_type":520,"total_length":8,"connstate":{"channel_id":103,"status":0}}
2017-04-09 14:33:33.520 (connecting): Got connection state response, connstate: NO_ERROR, channel ID: 103
2017-04-09 14:33:33.522 (idle): ...
Connected!
2017-04-09 14:33:33.528 (sendTunnReq): Sending TUNNELING_REQUEST_L_Data.req ==> {"header_length":6,"protocol_version":16,"service_type":1056,"total_length":22,"hpai":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"tunn":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"tunnstate":{"channel_id":103,"tunnel_endpoint":"192.168.1.17:3671","seqnum":0},"cemi":{"msgcode":17,"ctrl":{"frameType":1,"reserved":0,"repeat":1,"broadcast":1,"priority":3,"acknowledge":1,"confirm":0,"destAddrType":1,"hopCount":5,"extendedFrame":0},"src_addr":"15.15.15","dest_addr":"14/2/129","apdu":{"apci":"GroupValue_Write","tpci":0,"data":{"type":"Buffer","data":[255]}}}}
2017-04-09 14:33:33.528 (sendTunnReq): >>>>>>> seqnum: 0
2017-04-09 14:33:33.529 (sendTunnReq_waitACK): UDP send OK: TUNNELING_REQUEST_L_Data.req {"type":"Buffer","data":[6,16,4,32,0,22,4,103,0,0,17,0,190,208,255,15,114,129,2,0,128,255]}
2017-04-09 14:33:33.530 (sendTunnReq_waitACK): Inbound message: {"type":"Buffer","data":[6,16,4,33,0,10,4,103,0,0]}
2017-04-09 14:33:33.530 (sendTunnReq_waitACK): Received TUNNELING_ACK message: {"header_length":6,"protocol_version":16,"service_type":1057,"total_length":10,"tunnstate":{"header_length":4,"channel_id":103,"seqnum":0,"rsvd":0}}
2017-04-09 14:33:33.531 (sendTunnReq_waitACK): ===== datagram 0 acknowledged by IP router
2017-04-09 14:33:33.531 (idle): ...
2017-04-09 14:33:33.531 (idle): Inbound message: {"type":"Buffer","data":[6,16,4,32,0,22,4,103,0,0,46,0,190,192,255,15,114,129,2,0,128,255]}
2017-04-09 14:33:33.537 (idle): Received TUNNELING_REQUEST_L_Data.con message: {"header_length":6,"protocol_version":16,"service_type":1056,"total_length":22,"tunnstate":{"header_length":4,"channel_id":103,"seqnum":0,"rsvd":0},"cemi":{"msgcode":46,"addinfo_length":0,"ctrl":{"frameType":1,"reserved":0,"repeat":1,"broadcast":1,"priority":3,"acknowledge":1,"confirm":0,"destAddrType":1,"hopCount":4,"extendedFrame":0},"src_addr":"15.15.15","dest_addr":"14/2/129","apdu":{"apdu_length":2,"apdu_raw":{"type":"Buffer","data":[0,128,255]},"tpci":0,"apci":"GroupValue_Write","data":{"type":"Buffer","data":[255]}}}}
2017-04-09 14:33:33.537 (idle): 14/2/129: delivery confirmation (L_Data.con) received
2017-04-09 14:33:33.537 (idle): Sending TUNNELING_ACK ==> {"header_length":6,"protocol_version":16,"service_type":1057,"total_length":10,"hpai":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"tunnstate":{"channel_id":103,"tunnel_endpoint":"192.168.1.17:3671","seqnum":0}}
2017-04-09 14:33:33.537 (idle): UDP send OK: TUNNELING_ACK {"type":"Buffer","data":[6,16,4,33,0,10,4,103,0,0]}
^CTerminating
2017-04-09 14:33:37.086 (disconnecting): connection alive for 3.565 seconds
2017-04-09 14:33:37.086 (disconnecting): Sending DISCONNECT_REQUEST ==> {"header_length":6,"protocol_version":16,"service_type":521,"total_length":16,"hpai":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"connstate":{"channel_id":103,"state":0}}
2017-04-09 14:33:37.087 (disconnecting): UDP send OK: DISCONNECT_REQUEST {"type":"Buffer","data":[6,16,2,9,0,16,103,0,8,1,0,0,0,0,0,0]}
2017-04-09 14:33:37.087 (disconnecting): sent DISCONNECT_REQUEST
2017-04-09 14:33:37.087 (disconnecting): Inbound message: {"type":"Buffer","data":[6,16,2,10,0,8,103,0]}
2017-04-09 14:33:37.088 (disconnecting): Received DISCONNECT_RESPONSE message: {"header_length":6,"protocol_version":16,"service_type":522,"total_length":8,"connstate":{"channel_id":103,"status":0}}
2017-04-09 14:33:37.088 (disconnecting): got disconnect response
Note the 128 255 at the end of this line
UDP send OK: TUNNELING_REQUEST_L_Data.req {"type":"Buffer","data":[6,16,4,32,0,22,4,103,0,0,17,0,190,208,255,15,114,129,2,0,128,255]}
This request works and the dimmer is set to 100%
If I now change value to 1, it produces the following output:
$ node dimmer-test.js
Loading knx: KNXnet/IP protocol implementation for Node(>=4.x), version: 2.1.0
2017-04-09 14:37:15.383 (uninitialized): initializing connection to 192.168.1.17 (private)
2017-04-09 14:37:15.387 (uninitialized): candidate interface: en0 ({"address":"192.168.1.88","netmask":"255.255.255.0","family":"IPv4","mac":"b8:e8:56:36:7f:62","internal":false})
2017-04-09 14:37:15.387 (uninitialized): candidate interface: en4 ({"address":"192.168.1.82","netmask":"255.255.255.0","family":"IPv4","mac":"0c:4d:e9:a5:47:5c","internal":false})
2017-04-09 14:37:15.387 (uninitialized): IpTunnelingConnection.BindSocket
2017-04-09 14:37:15.395 (uninitialized): tunneling socket bound to {"address":"0.0.0.0","family":"IPv4","port":53082}
2017-04-09 14:37:15.395 (connecting): Connecting to 192.168.1.88...
2017-04-09 14:37:15.399 (connecting): Sending CONNECT_REQUEST ==> {"header_length":6,"protocol_version":16,"service_type":517,"total_length":26,"hpai":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"tunn":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"cri":{"connection_type":4,"knx_layer":2,"unused":0},"connstate":{"state":0}}
2017-04-09 14:37:15.401 (connecting): UDP send OK: CONNECT_REQUEST {"type":"Buffer","data":[6,16,2,5,0,26,8,1,0,0,0,0,0,0,8,1,0,0,0,0,0,0,4,4,2,0]}
2017-04-09 14:37:15.401 (connecting): Inbound message: {"type":"Buffer","data":[6,16,2,6,0,20,105,0,8,1,0,0,0,0,0,0,4,4,0,0]}
2017-04-09 14:37:15.405 (connecting): Received CONNECT_RESPONSE message: {"header_length":6,"protocol_version":16,"service_type":518,"total_length":20,"connstate":{"channel_id":105,"status":0},"hpai":{"header_length":8,"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"cri":{"header_length":4,"connection_type":4,"knx_layer":0,"unused":0}}
2017-04-09 14:37:15.405 (connecting): got connect response
2017-04-09 14:37:15.406 (connecting): Sending CONNECTIONSTATE_REQUEST ==> {"header_length":6,"protocol_version":16,"service_type":519,"total_length":16,"hpai":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"connstate":{"channel_id":105,"state":0}}
2017-04-09 14:37:15.406 (connecting): UDP send OK: CONNECTIONSTATE_REQUEST {"type":"Buffer","data":[6,16,2,7,0,16,105,0,8,1,0,0,0,0,0,0]}
2017-04-09 14:37:15.407 (connecting): Inbound message: {"type":"Buffer","data":[6,16,2,8,0,8,105,0]}
2017-04-09 14:37:15.408 (connecting): Received CONNECTIONSTATE_RESPONSE message: {"header_length":6,"protocol_version":16,"service_type":520,"total_length":8,"connstate":{"channel_id":105,"status":0}}
2017-04-09 14:37:15.408 (connecting): Got connection state response, connstate: NO_ERROR, channel ID: 105
2017-04-09 14:37:15.410 (idle): ...
Connected!
2017-04-09 14:37:15.417 (sendTunnReq): Sending TUNNELING_REQUEST_L_Data.req ==> {"header_length":6,"protocol_version":16,"service_type":1056,"total_length":21,"hpai":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"tunn":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"tunnstate":{"channel_id":105,"tunnel_endpoint":"192.168.1.17:3671","seqnum":0},"cemi":{"msgcode":17,"ctrl":{"frameType":1,"reserved":0,"repeat":1,"broadcast":1,"priority":3,"acknowledge":1,"confirm":0,"destAddrType":1,"hopCount":5,"extendedFrame":0},"src_addr":"15.15.15","dest_addr":"14/2/129","apdu":{"apci":"GroupValue_Write","tpci":0,"data":{"type":"Buffer","data":[1]}}}}
2017-04-09 14:37:15.417 (sendTunnReq): >>>>>>> seqnum: 0
2017-04-09 14:37:15.418 (sendTunnReq_waitACK): UDP send OK: TUNNELING_REQUEST_L_Data.req {"type":"Buffer","data":[6,16,4,32,0,21,4,105,0,0,17,0,190,208,255,15,114,129,1,0,129]}
2017-04-09 14:37:15.419 (sendTunnReq_waitACK): Inbound message: {"type":"Buffer","data":[6,16,4,33,0,10,4,105,0,0]}
2017-04-09 14:37:15.420 (sendTunnReq_waitACK): Received TUNNELING_ACK message: {"header_length":6,"protocol_version":16,"service_type":1057,"total_length":10,"tunnstate":{"header_length":4,"channel_id":105,"seqnum":0,"rsvd":0}}
2017-04-09 14:37:15.420 (sendTunnReq_waitACK): ===== datagram 0 acknowledged by IP router
2017-04-09 14:37:15.420 (idle): ...
2017-04-09 14:37:15.420 (idle): Inbound message: {"type":"Buffer","data":[6,16,4,32,0,21,4,105,0,0,46,0,190,192,255,15,114,129,1,0,129]}
2017-04-09 14:37:15.427 (idle): Received TUNNELING_REQUEST_L_Data.con message: {"header_length":6,"protocol_version":16,"service_type":1056,"total_length":21,"tunnstate":{"header_length":4,"channel_id":105,"seqnum":0,"rsvd":0},"cemi":{"msgcode":46,"addinfo_length":0,"ctrl":{"frameType":1,"reserved":0,"repeat":1,"broadcast":1,"priority":3,"acknowledge":1,"confirm":0,"destAddrType":1,"hopCount":4,"extendedFrame":0},"src_addr":"15.15.15","dest_addr":"14/2/129","apdu":{"apdu_length":1,"apdu_raw":{"type":"Buffer","data":[0,129]},"tpci":0,"apci":"GroupValue_Write","data":{"type":"Buffer","data":[1]}}}}
2017-04-09 14:37:15.427 (idle): 14/2/129: delivery confirmation (L_Data.con) received
2017-04-09 14:37:15.427 (idle): Sending TUNNELING_ACK ==> {"header_length":6,"protocol_version":16,"service_type":1057,"total_length":10,"hpai":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"tunnstate":{"channel_id":105,"tunnel_endpoint":"192.168.1.17:3671","seqnum":0}}
2017-04-09 14:37:15.428 (idle): UDP send OK: TUNNELING_ACK {"type":"Buffer","data":[6,16,4,33,0,10,4,105,0,0]}
^CTerminating
2017-04-09 14:37:16.905 (disconnecting): connection alive for 1.497 seconds
2017-04-09 14:37:16.906 (disconnecting): Sending DISCONNECT_REQUEST ==> {"header_length":6,"protocol_version":16,"service_type":521,"total_length":16,"hpai":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"connstate":{"channel_id":105,"state":0}}
2017-04-09 14:37:16.906 (disconnecting): UDP send OK: DISCONNECT_REQUEST {"type":"Buffer","data":[6,16,2,9,0,16,105,0,8,1,0,0,0,0,0,0]}
2017-04-09 14:37:16.906 (disconnecting): sent DISCONNECT_REQUEST
2017-04-09 14:37:16.907 (disconnecting): Inbound message: {"type":"Buffer","data":[6,16,2,10,0,8,105,0]}
2017-04-09 14:37:16.907 (disconnecting): Received DISCONNECT_RESPONSE message: {"header_length":6,"protocol_version":16,"service_type":522,"total_length":8,"connstate":{"channel_id":105,"status":0}}
2017-04-09 14:37:16.908 (disconnecting): got disconnect response
Now it sends the following:
UDP send OK: TUNNELING_REQUEST_L_Data.req {"type":"Buffer","data":[6,16,4,32,0,21,4,105,0,0,17,0,190,208,255,15,114,129,1,0,129]}
i.e. the value 1 has been encoded in the last 6 bits of the previous byte. This does not work and the dimmer remains at 100% as it was before.
I can't find a button to reopen the issue.
reopening
Thanks for the test script, I added it in as test-dimmer.js, Unfortunately I have no dimmer to test against. Here's the datagrams produced after the latest changes I've just made:
dimmer_control.write(100) ==> UDP send OK: TUNNELING_REQUEST_L_Data.req {"type":"Buffer","data":[6,16,4,32,0,22,4,4,0,0,17,0,190,208,255,15,114,129,2,0,128,255]}
dimmer_control.write(0) ==> UDP send OK: TUNNELING_REQUEST_L_Data.req {"type":"Buffer","data":[6,16,4,32,0,22,4,4,1,0,17,0,190,208,255,15,114,129,2,0,128,0]}
so it should be OK now...
BTW, you don't need to wrap the payload within buffers, that's what the datapoint type is supposed to exist for... Simply write the desired value:
binary_switch_datapoint.write(true);
dimmer_datapoint.write(100);
With the latest changes it seems to work correctly, I can write values both above and below 63 and it actually works to send in scalar values to datapoint.write() instead of passing in buffers. I also checked that the on('change') event for a datapoint fires correctly with the proper scalar values as arguments.
Thanks for your help!
You:'re most welcome
Στις 10 Απρ 2017 9:21 μ.μ., ο χρήστης "Mattias Holmlund" <
apologies, can you please be more concise? can you please provide some basic facts, such as 1) the value you've tried to write 2) the value that was written to the bus (either from enabling debug logging, or via ETS) 3) what is the 'proper'/expected value that you expected to see on the bus
Please note, I don't have access to "proper" documentation (only snippets that I googled around - only KNX-certified companies have access to deep technical documentation) so I don't have any "official" set of specs on which I can validate my library's behaviour with unit tests.