Bug fixed: sending new commands failed after 255 commands
Init process optimized
lots of functions now declared as local functions
What’s new in version alpha 7:
Support for Blyss added
Support for OWL CM180 added
Manual creation of Hasta (old models) added
Support for A-OK motors added
Support for weighting scale (BWR101/102, GR101) added (Ap15e contrib)
Support for Mertik-Maxitrol thermostats added (nirb contrib)
New callback SendMessage added
Last received message logged + stored in the variable “LastReceivedMsg” + displayed at the bottom of the Settings tab
New variable “AdjustMultipler” added to let the user apply a multiplier coefficient on weather data
Variable “Assocation” renamed “Association”
Error messages shown to the user in the status zone of the dashboard (blue zone at the top middle of the screen)
What’s new in version alpha 6:
Plugin is up to date with RFXtrx firmware v49
Child devices management revisited (fixed and enhanced)
Support for X10 security remotes added
Support for Meiantech/Atlantic security remotes added
Support for KD101 smoke detector added
Support for RUBiCSON temperature sensor added
Support for Viking 02035, 02038 humidity sensors added
Support for TFA 30.3133 temperature sensor added
Support for Hasta blinds added
Support for Philips SBC lighting added
New devices created to match remote controls and give ability to trigger Vera scene from remote buttons, plus new buttons to send specific commands like group off, dim, bright, mood, … etc
LightwaveRF panel suppressed from the main plugin device; replaced by a new dedicated device
Support for ATI and Medion remotes added
Setup of received protocols updated
“Logs” and “Notifications” panels added to barometer, rain, wind and UV devices
Ability to adjust reported values for temperature, humidity, UV and barometric sensors using the variable “AdjustConst”
Ability to repeat ON and OFF events for BinaryLight devices setting the variable “RepeatEvent” to 1
Callback added to simulate receiving of message (for testing purposes)
Support added for USB RFXtrx connected to a remote machine providing an IP access to a local serial port (using VSPE on Windows for example)
What’s new in version alpha 5:
plugin is up to date with RFXtrx firmware v45
add support for Ikea Koppla
add support for La Crosse WS2300 (temperature, humidity, rain and wind sensors)
add support for chime command (ARC protocol)
add support for Visonic PowerCode door/window sensors and motion sensors
add partial support for X10 security remotes (light management)
What’s new in version alpha 4:
plugin is up to date with RFXtrx firmware v42
RollerTrol supported (including a new setting to enable or disable receiving + a new button to create manually the Vera device)
UV sensors supported
Viking 02811 temperature sensor supported
Chris’s code relative to X10 security added (“tripped” status is now updated for X10 door sensors and X10 motion sensors)
fix for DisplayStatus definition in json files for better compatibility with Automator app
barometer, rain and wind devices include now UI5 events and so can be used as triggers in a scene
X10 security is partially supported (door and motion sensors are created but status is not updated; arm/disarm is not yet implemented)
What’s new in version alpha 2:
you can now create manually switch device, dimmable light device and window covering device using a new tab
Harrison curtain is now managed (device creation + Open/Stop/Close commands)
For LightwaveRF, a new tab includes 5 mood buttons (the command must have been received first one time; then it can be send by the Vera/RFXtrx)
conversion of device between binary light device, dimmalbe light device and window covering device is done automatically by the plugin depending on the received messages, or can be done manually by the user using the new tab (buttons “add xxx”)
you can now associate several devices using the “Association” variable. This is interesting when you have several controllers for one receiving device. One device for each controller will be automatically created by the plugin but then you can keep only one device and put the “id” of each others in the “Assocation” variable of the remaining device. The different “id” must be separated by comma. The “id” must be the altid minus the 3 first characters (suppress the “LS/” or “DL/” or “WC/”). Then, commands coming from different controllers will impact one unique device.
Here are the scene numbers to be used in a scene trigger:
– ON (activated) / OFF (deactivated): 1-16
– SET LEVEL: 17-32
– LOCK (activated) / UNLOCK (deactivated): 33-48
– OPEN: 49-64
– CLOSE: 65-80
– STOP: 81-96
– GROUP ON (activated) / GRUP OFF (deactivated): 100
– GROUP SET LEVEL: 101
– DIM: 102
– BRIGHT: 103
– ALL LOCK: 105
– MOOD1: 111
– MOOD2: 112
– MOOD3: 113
– MOOD4: 114
– MOOD5: 115
– PANIC (activated) / END PANIC (deactivated): 120
– ARM AWAY: 121
– ARM HOME: 122
– DISARM: 123
– PAIR (KD101): 124
– CHIME (ARC protocol only): 131-146
When a range of values is mentionned, it means the number depends on the unit code of the device (from 1 to 16).
My updated TODO list is now:
1 - create a description/help page
2 - release a first version to have the plugin available in the app store
I’m very interested to find out the answers to this… I’ve been uhm-ing and ah-ing over an RFXcom for ages, and this new stick may have just won me over…
the plugin is made for socket (LAN) communication. I have no experience with usb serial communication but the code should be easily adapted for this type of communication. I think usb however limits your possibilities and I therefore advise you to buy the networked devices.
I take a quick look to the code + the code of other plugins using serial port, and yes this is probably very simple to adapt.
But with USB RFXCOM, I imagine that we have only one communication channel to receive data and to send orders (instead of 2 in the case of the RFXLAN). I don’t know how are managed acknowledgments of orders. Are they “mixed” with normal data receiving ?
Bert (RFXCOM) told me he already delivered a USB RFXtrx433 to someone who will try to make a plugin for the Vera.
By curiosity, is it someone here present on the forum ?
I got confirmation from Bert (RFXCOM) that the new RFXtrx use a new protocol, different from the one used by RFXLAN in particular. This new protocol will be used in the future by new RFXCOM products.
That being said, that means we have to develop a new totally RFXCOM plugin that will handle the new RS232 protocol. I think I should be able to initialize this new plugin, even if I have until now no experience with lua/Vera development.
First I have to buy the new RFXCOM products + few Oregon sensors.
I suspect I’m the chap Bert was referring to regarding the Vera plugin, I was in touch with RFXCOM with a few tech queries and ended up being lucky enough to get hold of the new transceiver last week.
You’re right in that it uses a new protocol (in my opinion simpler), however it’s very well documented. I’ve been pretty much hobbled with work and am ashamed to say I’ve barely had a chance to try out the transceiver, never mind start coding a plugin.
While I was waiting to receive the new RFXCOM stick, I did have a look at the existing plugin code. I’m not hugely familiar with Lua/Luup but from an initial look it will need a reasonable rewrite - the LAN unit it’s written for used 2 different IP addresses for send and receive messages, it’s also operating at a slightly lower level than will be required with the USB stick.
My current plan is to have the RFXCOM installed on a PC somewhere with a small server side listen app running on the PC to check for signals from the Vera. The plugin will then take the IP address of the server PC and communicate with the server side app which will in turn communicate with the RFXCOM box as appropriate.
This of course is a stupid arrangement because the Vera has 2 USB ports - obviously it would be far better to have the RFXCOM plugged straight in. My problem with this is my unfamailarity with Lua/Luup, I think I’ve got a reasonable understanding i.e. I can see the code to steal from other plugins of sending and receiving messages and am therefore confident I can get this working, however I’ve not looked at talking direct to the USB ports on the Vera - maybe it’s easy, maybe it needs firmware support? I’m also partly keen on taking the server side app route initially as I’ve got a Tellstick / Dovado combo at the moment and it’s got a nice simple UDP API - if I develop this way then I can easily fork the plugin and have support for both.
If I’m realistic it will be the weekend at the earliest before I can lock myself away and start coding.
I’ll post anything usable as I develop it, if anyone writes anything in the meantime I’m happy to assist with testing / debug etc.
Mine has been purchased few minutes ago. I will receive it only in few days (one week or 2).
Could you please at least check that serial/USB is recognized by the Vera when you connect the RFXtrx to the Vera ?
(open a SSH session and check the result of dmesg command)
Regarding the plugin, it seems to be easier to handle RS232 through USB than through IP. There is no setting to add to the plugin, no connection to open (this is done automatically).
I will work on the plugin too. We can share our work if you wish. Even without any experience on lua, I think it is relatively easy to create the skeleton of the new plugin, taking examples from existing RS232 plugins.
On my side, I will implement in priority the decoding of temperature and humidity sensors (I will have only Oregon sensors).
On your side, what are the devices you manage with RFXCOM ?
Implementing all the protocol defined by RFXCOM is not something little but this can be done step by step.
No probs to check if the Vera is recognising the RFXtrx, might not be tonight though, still at work - maybe I’d get home sooner if I stopped checking forums
I’m happy enough to go down the RS232 route, I only bought the Vera once I’d bought the RFXtrx so wasn’t sure how easy that would be, more comfortable with IP myself.
I’ve exclusively got HomeEasy(UK) kit, but that’s going no where in terms of development. Currently controlling it via Tellstick but I was looking into both LightwaveRF (nice and cheap) and ZWave, got in touch with RFXCOM to confirm they supported all the HEUK kit and they told me about the RFXtrx which supports both HEUK and LWRF. Was not actually planning on buying anything but when I figured I could get the Vera and the RFXtrx and therefore control all my current gear and be able to control LWRF and ZWave kit from the same interface I emptied out my piggy bank…
Happy to work together on plugin, my main problem at the moment is finding free time to do it.
hub.c: new USB device 00:03.0-1.2, assigned address 3
usbserial.c: FTDI FT232BM Compatible converter detected
usbserial.c: FTDI FT232BM Compatible converter now attached to ttyUSB0 (or usb/tts/0 for devfs)
[/quote]
Next step - talking to it..
The easiest way might be to start from the code of the existing RFXCOM plugin.
Unfortunately, this is not very clear if the current RFXCOM plugin is working or not with UI5, and I would like to start from a clean and working basis.
Managed to find a little time to play last night. Being a “first princliples” sort of guy I thought I’d start off with some command line serial port comms, move onto Lua and then eventually graduate to Luup.
Unfortunately I didn’t really achieve anything apart from confirming my inexperience with OpenWrt, however on the offchance it saves someone else 2 minutes, here’s what I learned :
[ul][li]You need to use devfs notation to talk to the RFXtrx i.e. /dev/usb/tts/0 not /dev/ttyUSB0[/li]
[li]OpenWrt doesn’t come with stty or empty as standard[/li]
[li]That’s it…[/li][/ul]
Having failed at the bottom up approach I thought I’d try top down and find an RS232 Plugin and hack that at bit, however it was getting late and not seeing anything blindingly obvious I called it a night.
I looked at the datasheets of the rfxcom and the existing plugin over the last days (I was thinking of using it but ended up starting building my own transmitters/receivers for a different frequency band …). I would say that the existing plugin is too different to mod it to fit the usb variant. I would start new, maybe using some elements. If made generic it would give a lot of great options (for example the lightwaverf stuff)
I received today my RFXtrx. Not yet connected to the Vera. I just used the RFXCOM test application on my PC and unfortunately only 1 of my 3 new Oregon THGR122NX sensors is detected by the RFXtrx :-[ I don’t understand what could be wrong…
Edit: the RFXtrx firmware dated the 7th of March correct my problem 8) My 3 THGR122NX are now detected.
RFXCOM guys are pretty quick on tech support - hopefully they can look into it. There’s a msgcode for “undecoded packet” in the SDK, maybe you could catch them and forward.
Tellsticks now support Oregon and they’ve got big compatibility issues too.
Also - it’s worth trying limiting the packets it’s receiving i.e. limit the different kinds of hardware it’s scanning for, however I’d suspect this would be a reliability issue rather than a recognition one.
[quote=“redeyedrob, post:17, topic:170604”]RFXCOM guys are pretty quick on tech support - hopefully they can look into it. There’s a msgcode for “undecoded packet” in the SDK, maybe you could catch them and forward.
Tellsticks now support Oregon and they’ve got big compatibility issues too.
Also - it’s worth trying limiting the packets it’s receiving i.e. limit the different kinds of hardware it’s scanning for, however I’d suspect this would be a reliability issue rather than a recognition one.[/quote]
I tried to check “undecoded packet” but I got no additional information.
I have already setup the RFXtrx to receive obly Oregon and La Crosse.
I hope that a new RFXCOM firmware could solve the issue.
I hope these 2 new sensors are working well, I have nothing to test them exceopt the RFXtrx.
hub.c: new USB device 00:03.0-1.2, assigned address 3
usbserial.c: FTDI FT232BM Compatible converter detected
usbserial.c: FTDI FT232BM Compatible converter now attached to ttyUSB0 (or usb/tts/0 for devfs)
[/quote]
What is the version of your Vera ?
Here is what I get:
+usb 2-1: new full speed USB device using rt3883-ohci and address 2
+ftdi_sio 2-1:1.0: FTDI USB Serial Device converter detected
+usb 2-1: Detected FT232RL
+usb 2-1: Number of endpoints 2
+usb 2-1: Endpoint 1 MaxPacketSize 64
+usb 2-1: Endpoint 2 MaxPacketSize 64
+usb 2-1: Setting MaxPacketSize 64
+usb 2-1: FTDI USB Serial Device converter now attached to ttyUSB0
And it is recognized even behind my new little Amazon USB hub:
+usb 1-1: new high speed USB device using rt3883-ehci and address 2
+hub 1-1:1.0: USB hub found
+hub 1-1:1.0: 4 ports detected
+usb 1-1.2: new full speed USB device using rt3883-ehci and address 3
+ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
+usb 1-1.2: Detected FT232RL
+usb 1-1.2: Number of endpoints 2
+usb 1-1.2: Endpoint 1 MaxPacketSize 64
+usb 1-1.2: Endpoint 2 MaxPacketSize 64
+usb 1-1.2: Setting MaxPacketSize 64
+usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0
Ok, after reading few parts of the wiki and go through few existing plugins (RFXCOM, Onkyo, Denon, Panasonic, Pioneer, …), I think I have now the minimum basics to understand how it works and what is the role of each file.
What is exactly your idea when you think of making it generic ?
We have to define child devices, but it seems it is already what is done by the current RFXCOM plugin. Do you imagine a different architecture to make it even more generic than that ?
