664RE: [ukusa_gateway] Taken a few steps backwards!
- Nov 30, 2012
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 interface or maybe a C-Bus Ethernet interface. Regardless the 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 faster 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, level 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 only 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
- << Previous post in topic Next post in topic >>