Getting a Status Request with the Devkit

Hi!

I need to test the Status Report(1&2) so I'm trying to send a Status Request(09A0-1) with the DevKit. My problem is that my module doesn't seem to receive the Status Request cmd.

My module communicate with the C-Bus via Rs-232 using a 5500PC. I wonder if the Status Request is sent on the Rs-232 link?

 

I think I should give some other precision on my installation :

I use two 5500PC. The first is plugged in the PC for DevKit and the other is plugged on my module. When I send a status request with devkit, I can see the LED "Unit-Comms" of the 5500PC connected on the PC blinking, but not the 5500PC connected on my module. If my module is sending a cmd, only the LED of the 5500PC connected on it blink.

Maybe the Unit-Comms LED is flashing only when it is receiving data...

 

Good idea, ashleigh!

...

I tried using two devkit with the setting you gave but unfortunatelly, I didn't work. The receivind pci don't seem to see the status request that I'm sending with the other pci. I don't no if this can help you, but I logged the init of the receiving and receiving pci :

For the receiving :

Code:

Tx : ~~~<CR>
Tx :  = Set Basic Mode
Rx : ~
Rx : ~
Rx : ~
Rx : <CR>
Tx : ~~~<CR>
Tx :  = Set Basic Mode
Rx : ~
Rx : ~
Rx : ~
Rx : <CR>
Tx : A3300051<CR>
Tx :  = Set Default Mode
Tx : 2102<CR>
Tx :  = CAL, Identify  2 (Firmware version)
Rx : A3300051<CR>
Rx : 21028600000032300018<CR>
Rx :  = CAL, No-op
Rx : 860000008902342E332E303020208C<CR>
Rx :  = CAL, Reply, Parameter 2, 8 Bytes = 34 2E 33 2E 30 30 20 20
Tx : 1A2001<CR>
Tx :  = CAL, Recall Parameter 32, Count = 1
Rx : 86000000822000D8<CR>
Rx :  = CAL, Reply, Parameter 32, 1 Bytes = 00
Tx : 1A3001<CR>
Tx :  = CAL, Recall Parameter 48, Count = 1
Rx : 8600000082305177<CR>
Rx :  = CAL, Reply, Parameter 48, 1 Bytes = 51
Tx : 1A4101<CR>
Tx :  = CAL, Recall Parameter 65, Count = 1
Rx : 860000008241793E<CR>
Rx :  = CAL, Reply, Parameter 65, 1 Bytes = 79
Tx : 1A3E01<CR>
Tx :  = CAL, Recall Parameter 62, Count = 1
Rx : 86000000823E01B9<CR>
Rx :  = CAL, Reply, Parameter 62, 1 Bytes = 01
Tx : 1A4201<CR>
Tx :  = CAL, Recall Parameter 66, Count = 1
Rx : 86000000824206B0<CR>
Rx :  = CAL, Reply, Parameter 66, 1 Bytes = 06
Tx : 1A2101<CR>
Tx :  = CAL, Recall Parameter 33, Count = 1
Rx : 86000000822125B2<CR>
Rx :  = CAL, Reply, Parameter 33, 1 Bytes = 25
Tx : 1A2201<CR>
Tx :  = CAL, Recall Parameter 34, Count = 1
Rx : 86000000822225B1<CR>
Rx :  = CAL, Reply, Parameter 34, 1 Bytes = 25
Tx : ~~~<CR>
Tx :  = Set Basic Mode
Tx : A3300051<CR>
Tx :  = Set Default Mode
Rx : ~
Rx : ~
Rx : ~
Rx : <CR>
Rx : A3300051<CR>
Tx : 2100<CR>
Tx :  = CAL, Identify  0 (Manufacturer)
Rx : 8600000032300018<CR>
Rx :  = CAL, Acknowledge, Parameter 48, Code = 0
Rx : 860000008900434C495053414C20C9<CR>
Rx :  = CAL, Reply, Parameter 0, 8 Bytes = 43 4C 49 50 53 41 4C 20
Tx : 2101<CR>
Tx :  = CAL, Identify  1 (Type)
Rx : 86000000890150434C4F43414C34BE<CR>
Rx :  = CAL, Reply, Parameter 1, 8 Bytes = 50 43 4C 4F 43 41 4C 34
Tx : 2102<CR>
Tx :  = CAL, Identify  2 (Firmware version)
Rx : 860000008902342E332E303020208C<CR>
Rx :  = CAL, Reply, Parameter 2, 8 Bytes = 34 2E 33 2E 30 30 20 20
Tx : 1A2001<CR>
Tx :  = CAL, Recall Parameter 32, Count = 1
Rx : 86000000822000D8<CR>
Rx :  = CAL, Reply, Parameter 32, 1 Bytes = 00
Tx : 1A2306<CR>
Tx :  = CAL, Recall Parameter 35, Count = 6
Rx : 8600000087239EEB2479E79E25<CR>
Rx :  = CAL, Reply, Parameter 35, 6 Bytes = 9E EB 24 79 E7 9E
Tx : 2107<CR>
Tx :  = CAL, Identify  7 (Network voltage)
Rx : 86000000860732382E3956C6<CR>
Rx :  = CAL, Reply, Parameter 7, 5 Bytes = 32 38 2E 39 56
Tx : 1A2A06<CR>
Tx :  = CAL, Recall Parameter 42, Count = 6
Rx : 86000000872AB64DB4B68CDEF2<CR>
Rx :  = CAL, Reply, Parameter 42, 6 Bytes = B6 4D B4 B6 8C DE
Tx : 2104<CR>
Tx :  = CAL, Identify  4 (Extended Diagnostic Summary)
Rx : 860000008D042525FF7D83186DD138B9000455<CR>
Rx :  = CAL, Reply, Parameter 4, 12 Bytes = 25 25 FF 7D 83 18 6D D1 38 B9 00 04

And now the sending pci:

Code:

Tx : ~~~<CR>
Tx :  = Set Basic Mode
Rx : ~
Rx : ~
Rx : ~
Rx : <CR>
Tx : ~~~<CR>
Tx :  = Set Basic Mode
Tx : A3300051<CR>
Tx :  = Set Default Mode
Rx : ~
Rx : ~
Rx : ~
Rx : <CR>
Rx : A3300051<CR>
Tx : 2102<CR>
Tx :  = Local Network, Dest Unit 255, CAL, Identify  2 (Firmware version)
Rx : 21086FFFF003230001A<CR>
Rx : 86FFFF008902342E342E303020208D<CR>
Rx :  = Local Network, Source Unit 255, CAL, Reply, Parameter 2, 8 Bytes = 34 2E 34 2E 30 30 20 20
Tx : 1A2001<CR>
Tx :  = Local Network, Dest Unit 255, CAL, Recall Parameter 32, Count = 1
Rx : 86FFFF008220FFDB<CR>
Rx :  = Local Network, Source Unit 255, CAL, Reply, Parameter 32, 1 Bytes = FF
Tx : 1A3001<CR>
Tx :  = Local Network, Dest Unit 255, CAL, Recall Parameter 48, Count = 1
Rx : 86FFFF0082305179<CR>
Rx :  = Local Network, Source Unit 255, CAL, Reply, Parameter 48, 1 Bytes = 51
Tx : 1A4101<CR>
Tx :  = Local Network, Dest Unit 255, CAL, Recall Parameter 65, Count = 1
Rx : 86FFFF0082415168<CR>
Rx :  = Local Network, Source Unit 255, CAL, Reply, Parameter 65, 1 Bytes = 51
Tx : 1A3E01<CR>
Tx :  = Local Network, Dest Unit 255, CAL, Recall Parameter 62, Count = 1
Rx : 86FFFF00823E00BC<CR>
Rx :  = Local Network, Source Unit 255, CAL, Reply, Parameter 62, 1 Bytes = 00
Tx : 1A4201<CR>
Tx :  = Local Network, Dest Unit 255, CAL, Recall Parameter 66, Count = 1
Rx : 86FFFF00824200B8<CR>
Rx :  = Local Network, Source Unit 255, CAL, Reply, Parameter 66, 1 Bytes = 00
Tx : 1A2101<CR>
Tx :  = Local Network, Dest Unit 255, CAL, Recall Parameter 33, Count = 1
Rx : 86FFFF00822125B4<CR>
Rx :  = Local Network, Source Unit 255, CAL, Reply, Parameter 33, 1 Bytes = 25
Tx : 1A2201<CR>
Tx :  = Local Network, Dest Unit 255, CAL, Recall Parameter 34, Count = 1
Rx : 86FFFF00822225B3<CR>
Rx :  = Local Network, Source Unit 255, CAL, Reply, Parameter 34, 1 Bytes = 25
Tx : ~~~<CR>
Tx :  = Set Basic Mode
Rx : ~
Rx : ~
Rx : ~
Rx : <CR>
Tx : A3300051<CR>
Tx :  = Set Default Mode
Tx : 2100<CR>
Tx :  = Local Network, Dest Unit 255, CAL, Identify  0 (Manufacturer)
Rx : A3300051<CR>
Rx : 86FFFF003230001A<CR>
Rx :  = Local Network, Source Unit 255, CAL, Acknowledge, Parameter 48, Code = 0
Rx : 86FFFF008900434C495053414C20CB<CR>
Rx :  = Local Network, Source Unit 255, CAL, Reply, Parameter 0, 8 Bytes = 43 4C 49 50 53 41 4C 20
Tx : 2101<CR>
Tx :  = Local Network, Dest Unit 255, CAL, Identify  1 (Type)
Rx : 86FFFF00890150434C4F43414C34C0<CR>
Rx :  = Local Network, Source Unit 255, CAL, Reply, Parameter 1, 8 Bytes = 50 43 4C 4F 43 41 4C 34
Tx : 2102<CR>
Tx :  = Local Network, Dest Unit 255, CAL, Identify  2 (Firmware version)
Rx : 86FFFF008902342E342E303020208D<CR>
Rx :  = Local Network, Source Unit 255, CAL, Reply, Parameter 2, 8 Bytes = 34 2E 34 2E 30 30 20 20
Tx : 1A2001<CR>
Tx :  = Local Network, Dest Unit 255, CAL, Recall Parameter 32, Count = 1
Rx : 86FFFF008220FFDB<CR>
Rx :  = Local Network, Source Unit 255, CAL, Reply, Parameter 32, 1 Bytes = FF
Tx : 1A2306<CR>
Tx :  = Local Network, Dest Unit 255, CAL, Recall Parameter 35, Count = 6
Rx : 86FFFF0087239EEB2479E79E27<CR>
Rx :  = Local Network, Source Unit 255, CAL, Reply, Parameter 35, 6 Bytes = 9E EB 24 79 E7 9E
Tx : 2107<CR>
Tx :  = Local Network, Dest Unit 255, CAL, Identify  7 (Network voltage)
Rx : 86FFFF00860732382E3956C8<CR>
Rx :  = Local Network, Source Unit 255, CAL, Reply, Parameter 7, 5 Bytes = 32 38 2E 39 56
Tx : 1A2A06<CR>
Tx :  = Local Network, Dest Unit 255, CAL, Recall Parameter 42, Count = 6
Rx : 86FFFF00872AB64DB4B68CDEF4<CR>
Rx :  = Local Network, Source Unit 255, CAL, Reply, Parameter 42, 6 Bytes = B6 4D B4 B6 8C DE
Tx : 2104<CR>
Tx :  = Local Network, Dest Unit 255, CAL, Identify  4 (Extended Diagnostic Summary)
Rx : 86FFFF008D042525FF7D83FFFFFFFFB70004EB<CR>
Rx :  = Local Network, Source Unit 255, CAL, Reply, Parameter 4, 12 Bytes = 25 25 FF 7D 83 FF FF FF FF B7 00 04
Tx : \05D00009A0<CR>
Tx :  = Local Network, Multipoint, Security, Status Report 1 Request

 

My problem is that my module don't receive the cmd Get status(that I send with the Devkit) so it can't be tested for now (I checked in my software and in the hardware and the get status is defenetively not received).

I use two devkit on different comport(like you proposed). If I send a light on a devkit, the other see it, the inverses is true(and my module to if I plug it on the PCI). If I send a get status with a devkit, the other don't see it.

For now, my module can establish a communication with the C-Bus, send light cmd or react to light cmd that came from the C-Bus, replie to MMI status request, send the security cmd (like zone open), status report1&2 is coded(but cannot be tested!), etc. So my software should replie to a "Get Status 1" but the cmd is not event transmitted by the second PCI!

I don't understand why a simple light cmd pass from one PCI to another but not a Get Status of the security application!

 

The firmware version of my two PC Interface are :
4.4.00 and 4.3.00

 

This might be a definition problem.

A status request message in C-Bus is terminology that is often used to describe something we also call an MMI. This is a block of status information pertaining to a single application.
If you want to pass these messages to a module, you must set the "monitor" option. This causes any status reports on the local network to be processed and passed to the serial port of the PC Interface. This is separate from the "connect" facility which allows the PC interface to pass "SAL" (Specific Application Commands) commands to the serial port.

GetStatus commands, on the other hand, are "CAL" (Common Application Commands), and are only ever routed point-to-point. If you want to send a command from a PC through a C-Bus network, and back through the serial port of a second PC interface to your module, you must ensure that the entire path is specified. This is not a simple command, it is a multi-network command. Note that the PC Interface serial port "unit address" is always "00".

 

Oh no! not another status command!

OK. Now I see there is a great opportunity for confusion:

a Status Report (MMI)is not to be confused with a GetStatus (CAL) command, is not to be confused with Get Status 1 or Get Status 2 commands (SAL, Security application).

IF lighting commands are getting through with your configuration, the only thing that could be stopping the security application commands from getting through is the application addresses of the PC interface connected to your module. The PC interface application 1 address must either be $FF, or one of the two application addresses need to be the security application ($D0) in order for your test to work.

 

I don't know if I understand but when you talk of multi-network cmd, are you saying that I should send my "Status 1(or 2) Request" as a point to point to multi-point commands (witch include a network route)? If it's this, I don't have a bridge(if it's supposed to be an equipement)... For know I'm sending the Get Status as a point to multi-point command.

Don't worries, this is what I'm using since the beginning!

Reading this made me realizing a point : in the initialisation of my module I send @A32 to choose the lighting and air-cond application. Does this mean that the C-Bus Network will not send the security message (like Status 1 Request of security application) to my module? For testing purpose, I will change my initialisation to set FF as choosen application. If this work, I presume that my module will receive all the traffic of the C-Bus network witch could consume a lot of process time for filtering all this(for know I have a very small C-Bus network but on a real network, it could be catastrophic)? Is It possible to choose three application(light, air-cond and security)... What do you think is the best solution if all that I wrote above is correct? The problem could be easier if my module only had to send command for one or two application, but I this case, the module have to send/receive from the three applications...


Concerning the application address for the PCI, I don't know if this is a bug in the Devkit or simply something that I don't quite understand yet, but if "Hexadecimal number" are not checked in devkit, I can't choose application 0xFF in the set mode menu, I have to select 255(This is not the problem(!) I know that 255 = 0xFF). The problem is the cmd that is sent after I close the windows:
@A3210025500s<CR>
witch should be (I think) sent as
@A32100FF00r<CR>.
If the cmd is not sent in hexadecimal form, the PCI application don't seem to change to the specified address...

 

Ok, it looks like you are getting on the right track. Sorry, but there is no way to make a PC interface filter so that it passes messages for only 3 specific applications. You can set the filter to allow one to pass, two, or all (application 1 = $FF is a wildcard). I would not expect that you would have much trouble filtering out what you need if you allow the wildcard. Most networks in practice would have low rates of activity on applictaions other than lighting.

As for my comments on multi-network commands, you can actually send messages from one PC interface through a C-Bus network to a second PC interface's Serial port by treating the second PC interface as a bridge, and the serial port as a unit with address 00. A C-Bus PC Interface is actually implemented as a "bridge" to the serial port.