+- Comfort Automation/ Security System Forums (https://www.comfortforums.com)
+-- Forum: Third Party (interfacing to Comfort) (https://www.comfortforums.com/forum-5.html)
+--- Forum: alphaWerk UHAI RPi (Community Edition) (https://www.comfortforums.com/forum-136.html)
+--- Thread: Problems getting started (device network id must be unique) and a few other issues (/thread-4793.html)
- mattbrain - 11-16-2017
Hi Wexfordman
Really pleased you have it working - and you have finally realised your dream
I\'m currently working with Chiu on the hardware implementation which will take this integration to the next level - and resolve many of the little niggles reported on this forum.
I\'m hoping to have something exciting to share before the end of the year.
Thanks,
Matt
- wexfordman - 11-16-2017
Brilliant thanks Matt,
Just a quick question on status with regards to the status of devices in ST.
I can control devices, but I cannot see the status of them, is there a way of doing this so I can see the status as well ?
The status of a device is related to a comfort counter value, so there would need to be a way of alligning the counter value with the device ?
- mattbrain - 11-16-2017
Hi Wexfordman
Regular Comfort Outputs allow control and report back their status, as do alarm state controls. Comfort Inputs only report their status.
In terms of your request, I believe you have lights which are controlled via Responses and report their status via Counters. I believe to solve this we need create a device which allows control via Responses and reports status from Counters - and there are at least 2 ways we could do this.
1. Create a new device type which talks directly to the Comfort Bridge as do all the other Comfort controls in SmartThings. This would require a little development (probably by me or Ben, but I am happy to support another wiling volunteer) and could be added as an optional component in the same way that Response control is implemented.
2. Create a virtual device and use CoRE, webCore or other SmartThings code to link it to the associated Comfort Response and Counter Devices. This would probably be the quickest way to make this happen, although it isn\'t the most elegant (as it relies on other devices and creates a chain of dependancies).
Take a look at the behaviour of the Comfort Output devices as it transitions state - It goes from Off -> Turning On -> On. It has states \'Turning On\' and \'Turning Off\' along with error states \'Unknown\' etc. which represent the last know good state of the device. With a device which uses Responses to control it and receiving status via Counters we need to think carefully about how state should be represented and what happens if a light which is already on is turned on (does the counter send a further unsolicited update to reflect the same state).
I don\'t have access to a lighting system which does this, but I could try and pull something together if you are a willing to be a guinea pig - unless you or someone else fancies having a crack at it...
Thanks,
Matt
- wexfordman - 11-16-2017
Hi Matt,
More than happy to be a guinea pig and help out any way I can.
One other possible option, is maybe to look at the way it it is implemented in comfort itself, perhaps slychui can advise a bit here. Here is what I am thinking
Currently, comfort counters are represented in ST, so rather than create a respnse device for a light, maybe the approach is to get ST to update the counter value itself ?
Comfort can then do a response when the counter value changes, and this response could be to turn on or off the light.
I am a bit confused, or unsure of how to manage this triggering a loop though, I tried it on one light, and while it worked, I ended up with a disco in the living room, as everytime the counter value changed, the light toggled. I think a little bit more logic would solve this though.
Slychui, when I did this, I was using older comfort firmware, but is there a change in recent firmware whcih fixes this loop effect, or do you think this is a workable solution ?
- wexfordman - 11-16-2017
btw, if you want to try option 1, if you can give me a few pointers, I can see if I can muddle my way through it, although I have little to no coding experience
- slychiu - 11-16-2017
Matt, the is a problem with controlling by Response. When you specify a Response to execute, I believe you are actually using the Response number in a cclx file as it was at that time.
As you know, Response numbers can be changed by Comfigurator when you change or add Responses, as the software dynamically assigns Response numbers to fit into the response number space. This would cause the wrong Response to be activated.
Fixing the Response numbers prevents this from happening but it is not an ideal solution as you may forget, and sometimes responses may need to be unfixed it they cannot fit
In most of the external UCMs, eg Cbus, KNX, Zwave, Modbus we have moved away from using Responses. Instead the external devices are mapped to Counters, Flags, outputs, or inputs.
Mapping to Counters triggers the Counter Response. This does not depend on the Response number so the above problem does not apply.
If you use Counters, it can be used for control as well as feedback
- wexfordman - 11-16-2017
Hi Slychui,
But how do we stop the counter response from looping, for example, I just did the following test using latest firmware
Counter 59 (my velbus light counter) triggers response \"corridor light test\"
Corridorr light test does the following
if counter 59 =0,then do response \"corridoor light on\"else do response \"corridorr light off\"
So obviously when I do this, the minute I change counter 59 value I end up with a flashing light :-) This happens when I change the state locally even without triggering it from ST or anywhere else.
BTW, with regards to using ST response devices, I did fix all my responses in comfort so that they wont change response numbers.
- wexfordman - 11-16-2017
Doh!!
I think I just figured it out, hold on a few mins!
- mattbrain - 11-16-2017
Hi Chui, Wexfordman
Counters are fully supported by the SmartThings interface with the Counters device and should support this use model allowing both control and feedback. I haven\'t used Counters myself in anger so would be very interested in hearing any and all feedback.
Thanks,
Matt
- wexfordman - 11-16-2017
nope, sorry,
I changed the respnse code to
if counter 59 =0, then do response corridoor light off, else do response corridor light on.
Same thing, disco in the corridorr :-)
I am missing something here, so close, probably very obvious too!