665RE: [ukusa_gateway] Taken a few steps backwards!
- Dec 1, 2012
I’ve done some physical checking this morning. Wiring of the connector seems fine (checked with meter). I’ve gone over the instructions again just to check everything physically is in the right place. I’m plugging the HV into the LH socket (as you look at it) as per instructions. The short CBus cable you made (for the CBus PCI) is plugged in the RH socket (grey). I am a bit worried about the gateway instruction that says “DO NOT PLUG C-BUS into this socket if you don’t have a SIM , the gateway or C-Bus could be damaged”
As I don’t have a SIM, I wanted to be sure the RH socket is correct. The previous line seems to say that I should plug it into this one.
I doubt that I’ve changed the jumpers, but I thought I should check them also. This is JP5 with 6 header possibilities. From the RHS (with pin 1 on LHS), jumpers are at pins 2, 3 and 4, with the jumpers on the pairs of pins further away from the socket. Is this correct?
Thanks for the quick reply. I am using the serial interface. I have a feeling this might have been happening for some time as I can’t remember ever having seen the state of the CBus lights (although as I’ve never needed it until now, might have been there before). All commands to the interface are working though (I did get the scene setting triggers working after I wrote first). So I can control the whole CBus – just can’t see status of anything. I’ll check the cables to the RS232, but I think they look good at least.
The gateway is not able to see the C-Bus interface. I can't remember if you have the onboard C-Bus SIM or are using a C-Bus RS232 serial interf a! ce or maybe a C-Bus Ethernet interface. Regardless t he C-Bus interface is not being found. The first thing it does with C-Bus is to read the ID of the interface. It will have completed it's HomeVision synchronisation but will be unable to see or control anything on C-Bus.
I'll assume you've power cycled the gateway a couple of times and it does the same ?
This is likely caused by a physical change somewhere , probably in the cabling to the C-Bus RS232 interface or possibly the C-Bus interface IP address being wrong if you're using an Ethernet interface (which I dont think you are). if you're using an onboard SIM just check that it is seated correctly in it's socket.
On 30/11/2012 16:37, Ben Wilkinson wrote:
Things have gone a bit wrong today. I’ve been trying to use the buttons on switches to perform additional actions (to the scene setting they’re already doing). So that’s involved mapping the X10 actions to virtual CBus groups (which I then switch from within a scene). I have tried many things but not getting it to work. I think I’ve followed your Gateway instructions properly (I’ve certainly read it about 10 times!) but not having much joy. One issue seems to be that the gateway status page doesn’t show “Running ok”. It also doesn’t show the status of any of the groups correctly (or at least very many of them).
It shows: xAPRabbit : D: CB ID
Then, underneath the matrix display of lights:
Licence (xAP) CB HV MID:3268374032
C-Bus SIM ID 0 SID:0 ver none
Gateway ver beta 1 v22a 27th Jan 2009
Also I now can’t seem to trigger scenes from HV like I could before. The rest (old stuff) of the CBus light control is working fine.
Is there anything obvious I’m doing wrong you can tell ! from above message?
Thanks a lot for this Kevin. As usual, tons of useful info! I’m glad about the buffering. I thought I’ve occasionally had lights not go on when a few were switched at a time. But it’s unusual and I haven’t really taken much notice so may be mistaken.
Useful reminder on the keys. That had slipped my mind. I think I’ll just use some sort of virtual group to indicate if a button has been pressed (assuming this is possible). All I want to do in this ! circumstance is use it as an over-ride to automatic lighting so it should be fine. Pity it doesn’t show which key has been presse d! though as then I might have been able to do some quite interesting things.
< p class="MsoNormal">
Glad it's working Ben - best to avoid group 0 wherever possible I think. BTW you can control all lighting compatible applications on C-Bus this way, there are quite a few of them....
Scenes can be achieved either way - the approaches differ slightly however.
If you implement a scene directly on C-Bus then it is totally independent of HV and the gateway. The gateway does not know if a scene has been set or not although it does track every individual group change. It is actioned f! aster because the intermediary steps via the serial port are not required and also the exact messages sent out on C-Bus are compacted better. Scenes on C-Bus typically use the trigger application (202). There is also a scene indicator possibility where a button light indicates the scene is set and all members are still in ! the correct state. If one member group changes state this will be unset accordingly. You can also spread scenes across scene capbale switches etc. So if you had two DLT's for example some of the scene can be held in one and the remainder in the other. This will be your way around implementing large scenes Ben.
If you implement a scene on HV then it has to be triggered via a group change on the lighting (56) application. You can't use the trigger application. A scene within HV is essentially a HV macro that runs when something changes (your scene set key) and so you can implement ! anything that HV is capable of including conditional logic, delays, le vel calculations etc. which can be really powerful. IIRC in the current firmware you should now be able to send any sequence of lighting commands and not get buffer overflows as the messages are concatenated correctly or split across separate C-Bus command s! as needed. If that's not the case let me know. ; There is also no automatic maintainance of a 'scene valid' indicator within HV so you are not aware if a group within your scene changes state, thus breaking the scene. You could implement this via a macro if you wanted to know though.
One thing just to clarify..... pressing a key on C-Bus doesn't actually send a message at all.. only if a key is linked with a group do you see the command to change that group state go out. You don't know where (which key) originated the message from within HV although it maybe shows in the xAP message (origin=). Also a group onl y! maintains a state on C-Bus if it is present in an output unit e.g. a relay or dimmer. If the group is not present in an output unit then it's called a virtual group. Virtual groups are tracked by HV correctly so you can effectively treat them the same. However an indicator light on C-Bus will not track the state of a virtual gro u! p and should you restart the gateway it will not be able to recover the current state of a virtual group from C-Bus.
This email has been scanned by Netintelligence
This email has been scanned by Netintelligence
- << Previous post in topic Next post in topic >>