Adding an action to clear RxCode is a good idea. I’ll add that to the mod list. If you want to have a delayed clear in your scenes, use the following Lua. Place this in the scene’s Luup tab:
[code]function clearRxCode()
local dID = 123 – Change to device ID of KiraRx
luup.variable_set(“urn:dcineco-com:serviceId:KiraRx1”,“RxCode”,“”,dID)
end
luup.call_delay(“clearRxCode”,3) – Change to number of seconds delay
return true
[/code]
There is a possible problem with this approach. It is the reason that I have not yet built it into the plugin. When KIRA/KiraRx receives a string of IR commands, they get processed one by one. Clearing RxCode after a delay may step-on a following command. I think it is unlikely that this would prevent a scene being triggered but it is possible.
One solution is to check the current RxCode and only clear it if it hasn’t changed. I am considering that for a more general solution in the plugin.
OK. Would somebody like to try a new version of KiraRx that allows repeated codes?
This version now has an Options variable. The relevant option is ART=n where n is seconds. I am currently defaulting this to ART=3 (you will see this on the Advanced tab after Reload & Refresh).
When ART=n is specified and n is not zero, KiraRx will allow the same code to be repeated if it arrives at least (>=) n seconds after the last time it was received. This only applies to codes that are repeated without anything else being received in between them. If the ART option is not specified or n is zero, it works the same as it always has.
To allow the code to repeat, KiraRx clears RxCode and then waits 10 milliseconds before setting the code name again. On my system, this is sufficient time for scenes and PLEG to trigger. You can see it working (on UI5 anyway) because the UI shows Received: go blank and then reappear.
To try it out, upload I_KiraRx.xml and S_KiraRx.xml then Reload and Refresh. I would appreciate some feedback on this before I roll it into the main download.
I just downloaded the files and did a test to see if it worked. Nothing broke so that’s fine ;). The ART=3 Option is there but the scene does not trigger again in my situation.
My system is running UI7 though so maybe the 10 msec needs to be stretched a bit?
I have restored the code clearance with Luup after running the scene so do not need this function but I agree that your solution is better, more intuitive and should be implemented to improve the plugin for users not wanting to mess around with luup.
So maybe I will try later today to stretch the 10 msec, I noticed in the code that you provided the CCT option for that.
The ART=3 Option is there but the scene does not trigger again in my situation. So maybe I will try later today to stretch the 10 msec, I noticed in the code that you provided the CCT option for that.
Thanks for the feedback. If you could try a larger value of CCT that would be very helpful. If 50ms or 100ms still doesn’t permit a re-trigger, please let me know. It may be that UI7 requires a different approach.
@RexBeckett. Many thanks for the modification. I just tried it now (sorry I didn’t notice your post before today).
So far it works well for me on the default, so I am very happy indeed. I can now simplify multiple scenes because of this modification. Much appreciated.
[quote=“RexBeckett, post:221, topic:175170”]Thanks for the feedback @jtmoore.
Adding an action to clear RxCode is a good idea. I’ll add that to the mod list. If you want to have a delayed clear in your scenes, use the following Lua. Place this in the scene’s Luup tab:
[code]function clearRxCode()
local dID = 123 – Change to device ID of KiraRx
luup.variable_set(“urn:dcineco-com:serviceId:KiraRx1”,“RxCode”,“”,dID)
end
luup.call_delay(“clearRxCode”,3) – Change to number of seconds delay
return true
[/code]
There is a possible problem with this approach. It is the reason that I have not yet built it into the plugin. When KIRA/KiraRx receives a string of IR commands, they get processed one by one. Clearing RxCode after a delay may step-on a following command. I think it is unlikely that this would prevent a scene being triggered but it is possible.
One solution is to check the current RxCode and only clear it if it hasn’t changed. I am considering that for a more general solution in the plugin.[/quote]
If I have any code that needs to reset the state of something after a delay (e.g. turn the porchlight back off 5 minutes later), I record the timestamp of each event in a global and also pass that value as the optional third param of luup.call_delay. if the values differ when I check inside the delayed function, then a newer event has occurred. This approach works quite well, but I’m usually not dealing with half a dozen events in the same second. Since each IR code is processed in order in the same thread, you could easily just increment a counter variable and pass that counter to luup.call_delay instead of a timestamp.
It’s also worth pointing out that if every IR code that’s received triggers an individual call to luup.call_delay, then you must keep the delay to a very short interval (seconds not minutes!). I have not experimented to find a hard upper bound, but if you had several hundred threads spawned via luup.call_delay your vera could crash.
EDIT: I just read the rest of the thread and noticed you took a different approach. nevermind then.
I’ll give it a try on UI7 in a day or two. On the previous version I only made some minor changes to the json so it looks a little nicer. Other than that it worked right away.
I just downloaded the files and did a test to see if it worked. Nothing broke so that’s fine ;). The ART=3 Option is there but the scene does not trigger again in my situation.
My system is running UI7 though so maybe the 10 msec needs to be stretched a bit?
I have restored the code clearance with Luup after running the scene so do not need this function but I agree that your solution is better, more intuitive and should be implemented to improve the plugin for users not wanting to mess around with luup.
So maybe I will try later today to stretch the 10 msec, I noticed in the code that you provided the CCT option for that.
Will let you know.
Hans[/quote]
@HansW, I just loaded KiraRx on a Vera Edge running UI7 V1.7.906. I find that the repeat logic works correctly with the default 10ms CCT setting and triggers a scene as expected.
If you are still having problems, check LuaUPnP.log at the time you send the repeated code. You should see the RxCode variable change twice with 10ms between.
This is a temporary fix for running KiraRx under UI7. It just cleans up the display. Upload the file KiraRx.json using Apps → Develop apps → Luup files → Upload and, when Vera has reloaded, refresh your browser. This is not for use on UI5.
It also appears that the remote control icon is no longer provided as standard in UI7. If you want the proper icon displayed, download the attached png file and copy it to Vera folder /www/cmh/skins/default/img/devices/device_states. This is easy to do using WinSCP. See the attached notes. If you are using Vera Edge, follow the instructions for Vera Lite to find out your root password.
I have published a new Kira plugin in the App Store. KiraRT combines the functionality of KiraRx and KiraTx. Once an IR code has been learned or imported, it can be recognized and used as a scene/PLxx trigger and also transmitted through the Kira module’s IR emitter using the SendIRCode action. As an added advantage, if the EKC option is set, received and recognized codes can be automatically re-transmitted.
The dual functionality has necessitated a new structure for the stored IR codes. I recommend that the database is built by learning or importing each code. It is possible, though, to create the new structure from existing KiraRx and KiraTx saved codes. I have attached Lua code to perform this conversion. First backup both KiraRx and KiraTx codes using the Backup button on each device. Paste the converter code into Vera’s Test Luup code (Lua) window or use LuaTest. Change the device numbers at the top of the code to match your system and then execute the code. Now click the Restore button in KiraRT to load the converted code database. Note that, codes converted only from KiraRx, cannot be transmitted.
KiraRT has a number of features that can be enabled or customized by using the Options variable. See the User Guide for more details.
I have changed the way in which the IP address and port of the Kira module are specified. KiraRT uses Vera’s ip attribute instead of the separate variables used in KiraRx and KiraTx. KiraRT works with a single Kira module as specified by the IP address and port set in the ip attribute. If you have multiple Kira modules, you must create a separate KiraRT device for each one. Each Kira module should be configured to use a different port as well as a unique IP address.
In other respects KiraRT works the same way as KiraRx and KiraTx. It includes the recently added feature to permit repeated codes to retrigger scenes/PLxx. Imported Kira codes may also include the special repeat suffix. This does not affect code recognition but causes the codes to be repeated when sent.
If you install KiraRT on a system that already includes KiraRx and/or KiraTx, you will need to change the IPaddr and/or IPport setting of these to unused values to allow you to test KiraRT. The two generations of plugin cannot share the same Kira module.
KiraRT can be used on both UI5 and UI7. When installed on UI7, the plugin moves certain files during the first initialization. It will require an addition Reload Luup and browser refresh before the device UI is displayed correctly.
KiraRT can be installed from here if running UI5 or via UI7’s Apps → Install apps.
Hi Rex. Glad to see the update! I am thinking about replacing the previous RX and TX versions. I have a lot of lua code using both. Not sure if I am willing to update a lot of lines.
It will use a little more memory due to the changed structure of the IRCodes variable. A typical 52 bit code would use about 270 more bytes in KiraRT than it would in KiraRx. Double that if you backup the codes. If you use the converter code to translate codes from KiraRx to KiraRT, it will not need the extra memory, though. New learned or imported codes will, however. Overall the memory impact is not large unless you have a big set of codes.
KiraRT is mostly an advantage for users who want to send IR as well as receive it. Here it saves memory over the KiraRx + KiraTx combination. If you only want to receive codes, it doesn’t really have any advantages - at the moment.
I have not yet decided whether to publish KiraRx in the App Store. I do not expect to publish KiraTx as I think KiraRT is a better solution and is already fixed for UI7. I would encourage new users to start with KiraRT even if they do not expect to send IR codes.
I just started replacing my two Kira rooms with the new RT. I have not been able to replicate the functionality I had with Kira Rx and Tx. I had the Kira modules in the living room and bedroom set up with different IPs and sharing the same port number. This allowed me to send the same codes from each room. I haven’t been able to set the second KiraRT to use the same (shared) port number as before. The message displayed is: cannot bind to port xxxxx. Any suggestions would be appreciated!
I haven't been able to set the second KiraRT to use the same (shared) port number as before. The message displayed is: cannot bind to port xxxxx. Any suggestions would be appreciated!
Hi Mark, I did mention that this was a difference between KiraRT and KiraRx. It attempts to bind to a specific port so they must be unique.
One KiraRT device should still be able to receive codes from multiple Kira modules that are set to the same port (with different IPs) but it will only be able to send to the single IP address it is set for.
If you explain how you would like it to work, I may be able to come-up with something.
Thanks Rex for the quick reply! I have about 1/2 of the code converted. Not as much work as I expected. What I have completed works perfectly!
One KiraRT device should still be able to receive codes from multiple Kira modules that are set to the same port (with different IPs) but it will only be able to send to the single IP address it is set for.
I have not been able to get the two KiraRT modules configured to use the same port (normal - if I am understanding this correctly). The first KiraRT works as expected. When I add the second KiraRT using the same port this message is displayed: cannot bind to port xxxxx. Before I switched to KiraRT I had a living room Kira Rx and Tx. I had a Kira Tx in the bedroom. The bedroom remote commands were accepted and operated through living room Kira module.
I have two Kira modules. One in the master bedroom. The second is in the living room. I use two Pronto remotes (one for each room). Several of the bedroom remote commands are used to control the same devices as the living room. For example: toggle the alarm chime function (+ many more). I guess I could create additional triggers but there quite a few. Hope this makes sense. Kind of confusing for me. Another option might be to use one KiraRT and one KiraTx.
It looks like my attempt to simplify the way KiraRT works (wrt KiraRx + KiraTx) has made things harder for you. Sorry.
I had envisaged that there would be one KiraRT device for each Kira module - each of which used different ports.You could get your functionality by having two triggers for any common scenes as you have already realized.
If you set two Kira modules to have different IP addresses but the same port number, one KiraRT device will be able receive from them both but only transmit to the one corresponding to its defined IP address. You could use a KiraTx to send to the second device but it would not be able to learn codes. You would be able to import codes that you had learned with KiraRT, though.
At the moment I cannot think of an easy alternative. I was never happy with the old KiraRx/KiraTx cross-communications. You and I are probably the only ones who could make it work successfully with multiple Kira modules.
