PDA

View Full Version : User plugin for EnOcean USB300



hoox
August 27th, 2016, 11:14 AM
Hi everyone,

I'm trying to do a Girder 6 plugin for TCM3x0 based transceivers like the USB300.
The basic functionality is working, but that could take a while to finish, so here it is if someone wants to experiment and help.

The plugin allows to use these modules with the Device Manager:

- Dimmers and relays (control and status by RPS or preferably Central Command telegrams).
- Four-bytes sensors (with a default profile and some specifics, like simple temperature and Automated Meter Reading for electricity).
- One-byte sensors.

If it's not clear how to use it please let me know.

So far the UI is the most difficult part. If you have any tips about the JS publisher, that would be really appreciated!

Yoggi
September 4th, 2016, 08:38 AM
Hi hoox,

I was beginning to think that I was the only one interested in EnOcean for Girder here.

I tried your Enocean plugin on my Windows 10 machine and it works fine, so fare I have only tested basic stuff like turning on and off (EnOcean RCM250 Module) a lamp from within the Device Manager.

This is grate but I would like to run Girder on a Raspberry Pi 3 so I need it to work on Linux. You are right, your module doesn’t work on Linux (I tried in order to see what errors it would throw) and it is looking for a module “wim” (as you mention in your readme). Were do I find information about this module, I can't seem to find any information about it (no luck with google).

I have done some attempt of my own to control EnOcean devices (rudimentary at best), I have manage to calculate CRC8 and send messages but I have not manage to receive (do to ESP3 flexible packet length). I was hoping to use Girders built in transport but the parser is unfortunately not flexible enough.

I have asked Ron if he could make it more flexible and generic see post (https://www.promixis.com/forums/showthread.php?22231-Parser_variable_length), I am hoping that he will see this additional beneficial to other Girder users and find time to add it.

If I may ask, do you have any plans to try to make your plugin to work on Linux/RPI3?
If so would you benefit from an upgraded parser or would you go an other rout?

I would love to see you plugin on Linux so if there is anything I can help you with let me know! But remember I am not a real programmer, merely an enthusiast and a novice at programing.

Regards,

Joachim

hoox
September 4th, 2016, 03:16 PM
Hi Joachim,

the lack of interest is a bit surprising. It's very nice stuff, especially when combined with Girder.

About Linux compatibility:
The 'win' library is only documented in the Girder 5 Help but is available in Girder 6.
This plugin only uses one of it's functions to know the interval between PTM telegrams (which is what differenciates a switching and dimming command with RPS).
I do not know if Girder 6 has a Linux compatible method to generate timings in millisecond, so I'll try with a timer and a Lua counter and see if there is no significant loss on performance and precision.

A dynamic parser would be a great addition. At the moment the plugin uses the PARSER_PASSTHROUGH type. I think that it should handle variable length telegrams... At least the sensors (including PTM switches) should trigger events.
If it doesn't please set the log level to 2 or lower on the Component page and send me the Lua console output with the exact module model and what you're trying to do.

Also, I'm not sure if you're expecting to receive something from the RCM250 or another module type...
If I'm not mistaken, the RCM250 is a one way receiver (pre-Dolphin). Configuration and sync are much easier with the newer actuators. Be careful before buying, the documentation is often incredibly vague.

Yoggi
September 5th, 2016, 12:12 PM
Hi,

Yes a Linux version would be highly appreciated so please try to do away with 'win' if you can.

But first I would need to get your current version working properly, I can’t get beyond the basics.

I have added the Enocean plugin (File > settings > Plugins), gone to the Device Manager, Add Component, selected EnOcean plugin (Plugin Picker window) selected com-port (com3).

So fare so good, from Component Editor I can Send transceiver telegrams;

I select ID (Base ID of USB300 or base id + one, both already learnt by RCM250).

Next I select Rocker B and when I press button I or 0 the light is turned on and off.

So your plugin works, what I can't get to work is add device and have them sending commands.

I right click on the EnOcean component and select Add device from the window that pops up I select Relay and then Ok and this generates a Switch. I'll configure this switch by selecting a known transmitter (I select one of the previous working id's) then I select Rocker typ B and then parameter. I have tried both (S)OI and (S)IO and I press the Add learned transmitters button. Now the window below gets populated e.g XXXXXXXX:B(SIO) I finishing by hitting the Ok button.

From what I understand I should now be able to test the added switch by pressing the toggle button, but nothing happens.

Am I missing something? Do the relay need to be bidirectional (I know that RCM250 is not)?

Regarding actuator/relay, I am looking to get a bidirectional version maybe with dimmer functionality, do you have any good experiences? If so what brand and model?

Regards,

Joachim

hoox
September 6th, 2016, 02:51 PM
Hi Yoggi,

Hopefully the updated version (at first post) can run with Linux.

You did everything right. RPS commands from the DM devices weren't working for relays. It should now, but only for switching button mode like you have, the others will come later.

Regarding what modules to choose: bidirectional from any brand (they should all be compatible), easy to replace. It seems that most sensors are unidirectional but that's fine. If they clearly tell the EEPs they're using that's very good.

Yoggi
September 7th, 2016, 06:01 AM
Hi hoox,

In Windows I can now add a relay and configure a switch to send on and off (with toggle button on Control Editor page), I can also use and configure the switch (on off toggle) in Girder so this is great!

Regarding the UI, When I set up switch rocker there is a parameter drop down menu were I can select (S)OI (S)IO among others, if I understand correctly these are button press and release (this makes sense since my physical switch sends messages on press and release). If my interpretation is correctly maybe this could be clarified, OI and IO made little sense to me at first.

Now to the big problem under Linux, the drop down menu ID on the Component Editor don't list anything so I can't select the EnOcean gatway.

When I add the Enocean component I do get the correct ports in the drop down menu to select from (TtyUSB0 and ttyAMA0).

I have tried the USB300 (ttyUSB0) on Raspbian and Ubuntu but with no luck.

I have an EnOcean Pi on my Raspberry Pi so it would be nice to use it but getting the USB300 to work would go a long way!

The EnOcean Pi uses the Raspberry built in serial port TtyAMA0 (EnOcean Pi - A Wireless Transceiver Module for the Raspberry Pi)

Did you see my post (https://www.promixis.com/forums/showthread.php?22156-Programmer-for-Girder-EnOcean-driver-wanted)? Maybe there is some code that you can reuse or get inspired from!


Please let me know if there is anything I can help you with!

Regards,

Joachim

hoox
September 7th, 2016, 02:00 PM
Well, thanks Yoggi for testing!

The confusing 'parameter' is needed so that Girder can track the module status for each button (necessary for unidirectional modules).
It's just a compact form of the mode, the active buttons and their function (the first button is the OFF/- state, the last one is the ON/+ state).

The actuators usualy have factory function programing for two buttons, one button, momentary operation, and a lot more.
It's impossible for me to support them all, so I'll just do the simple and most commonly used modes: switch, toggle and momentary.
The default mode is the switch (S), with O = Off, I = On, but it is not a standard at all, so you can choose what each button actually does.
If the module has a status telegram, you can use only that, unless you want to update a bit sooner. Again, not all of that is working yet.


The Linux issue might just be a com port name format problem in this plugin. Please do another attempt with the 0.3.2 version. It should print the port it's trying to access.

If it still doesn't work, can you connect the USB300 with the Simple Transport Plugin?
You should get events in the logger (e.g. when using a PTM) with these settings:
Baud: 57600
Incoming parser: Passthrough
Create Events and Receive data as hex: checked

Yoggi
September 7th, 2016, 09:14 PM
Hi hoox,

If I hard code self.port to 'ttyAMA0' (line 1125 in TCM.lua) the plugin connects but after it connects I get an other error/message on the Lua console. And the Gateway Id drop down (Component editor) list doesn’t get populated.

New message/error:
Thu Sep 8 02:38:42 2016 ttyAMA0 TIMEOUT OCCURED WITHOUT DATA.

If I print the port parameter function connect receives I get 'dev/ttyAMA0' (looks like dev/ should be removed). Not sure were you construct the string but it sounds like an easy fix. I would look but I am out of time for now.

Tomorrow I will try with the USB300 and not the EnOcean Pi (the results above are with the EnOcean PI).

Regards,

Joachim

hoox
September 8th, 2016, 03:54 AM
Alright, you should get 'ttyAMA0' with the latest (0.3.3) as it should only take the string after the last backslash or slash.

Yoggi
September 8th, 2016, 11:31 AM
Hi hoox,

Some progress!

Windows returns com port path with backslash while Linux uses forward slash so I needed to change \\ to / in order to get a connection under Linux.

local _, _, d, port = string.find(component.internalId, '\\\\(.+)\\(.+)')
(line 346 backEnd.lua)

Not sure what the best way to handle this in Windows and Linux is. If I understand correctly Lua can use / in file path on both windows and Linux, maybe substitute \ with / when these are received from windows.

On Linux I can now add a switch, and the test ToggleButton works (Control Editor) to turn the RCM250 relay on and off.

On Window I can drag a switch (Control Editor) to Girders Action Tree but in Linux (Girder on Ubuntu with USB300) I can't.

I appreciate you taking time to make your plugin Linux friendly!

hoox
September 9th, 2016, 03:23 AM
If I understand correctly Lua can use / in file path on both windows and Linux, maybe substitute \ with / when these are received from windows.
Yes, it will do that.



On Window I can drag a switch (Control Editor) to Girders Action Tree but in Linux (Girder on Ubuntu with USB300) I can't.
I do not know why, so can you tell me if the Device Manager action (from the left Action tree) works as expected, and if drag'n drop works with the Device Manager Example Component?

Thanks!

Yoggi
September 9th, 2016, 07:15 AM
Hi hoox,

Device Manager action (from the left Action tree) works as expected! Drag'n drop with the Device Manager Example Component doesn’t ether work. This problem seems to be Ubuntu (15.04) related as your plugin works as expected on the Pi running Raspbian (Jessie). Not sure why this is but it is not a problem with your plugin and not a problem for me as I intend to run Girder on the PI.

So the only current problem (at least for the time being) is that I can't use the EnOcean Pi on the Raspberry Pi. I wonder why it doesn’t work, the USB300 and EnOcen Pi uses the same TCM310 chip?!

When I test with Girder and a Lua script (transport) USB300 and EnOcen Pi works in the same way when it comes to send and receive (the only change is the specified serial port 'ttyAMA0' or 'ttyUSB0') ESP3 messages. Any idea what could be causing the 'ttyAMA0 TIMEOUT OCCURED WITHOUT DATA' message/error?

I think this is fantastic, how do I buy you beer?!

Regards,

Joachim

Small correction, not sure if the drag and drop problem is a problem on Raspbian, as I used Girders frontend on Windows and the backend on the Pi, so it might be a Girder Linux problem.

hoox
September 10th, 2016, 02:46 AM
Any idea what could be causing the 'ttyAMA0 TIMEOUT OCCURED WITHOUT DATA' message/error?
The port could be already used, maybe by another application... As your transport script is ok with it then a problem in the TCM file is more likely. The new version fixes some connection bugs (and others), but I doubt it will fix yours.
You can check if the connection settings and timeout values are the same as your script.

Yoggi
September 15th, 2016, 05:51 AM
Hi hoox,

Sorry for the late reply, I have been away a few days.

My findings with the latest version 0.3.5 (remember I am not a programer so I could be wrong).

In order to get your code working on Windows and Linux I need to change the '\\', '//' substitution to '\\', '/'. I assume that the use of double backslash are do to that the backslash needs to be escaped (but forward dose not so it should only be replaced with one).

local linuxFormat = string.gsub(component.internalId, '\\', '/')

Since Windows returns different numbers of backslash in port path I need to change '// to '/+ at the beginning ('\\.\COM3' → '//./COM3' vs '/dev/ttyAMA0').

local _, _, d, port = string.find(linuxFormat, '/+(.+)/(.+)')

Remember the problem I had on the Pi with EnOcean Pi? TIMEOUT OCCURED WITHOUT DATA (I got this after the port got connected so its not that the port is used by an other program)

Now I get the same error on windows(and Ubuntu with the USB300) with the USB300 'COM3 TIMEOUT OCCURED WITHOUT DATA' after I have switch the relay on and off a few times.

From what I can see, our connection settings and timeout values are the same were it matters.
“You can check if the connection settings and timeout values are the same as your script? (your question in previous post)

I hope that my findings can help you, and if there is anything you would like my to try, let me know!

Joachim

edit
One thing I noticed regarding the EnOcean Pi (TCM310) interface is that the BaseID drop down newer gets populated (Component Editor page), maybe there is a slight difference in how this is read in.

hoox
September 17th, 2016, 10:26 AM
Thanks for the corrections, they are included in the latest update.

I could finally get the timeout error and stop the plugin when sending a lot of commands (never after the connection or moderate use).
However this bug could not be reproduced with the new version. See if it runs better for you too.


One thing I noticed regarding the EnOcean Pi (TCM310) interface is that the BaseID drop down newer gets populated (Component Editor page), maybe there is a slight difference in how this is read in.
The plugin will wait a second after the connection before reading the BaseID, and the radio receiving part is enabled first: check the Lua console when using a PTM (with Log set to 0).

Yoggi
September 17th, 2016, 05:34 PM
Hi hoox,

I did some more testing with a transport script and I noticed that I didn’t get the sync byte in the beginnings of the messages. I would aper that when I did the remapping of the serial port (on the Pi 3 the hardware serial port has been mapped to blue tooth) that the EnOcean Pi needs I made a small mistake (I needed to remove all trace of console debug in /boot/cmdline.txt).

So your plugin works fine with the EnOcean Pi. I apologise for not catching this earlier and for leading you up the garden path!

I will do some more testing, now that I have my intended hardware working.

Thanks for your grate work on this plugin!

Joachim

hoox
September 18th, 2016, 02:35 PM
Ahhh, it's great to know that your EnOcean Pi is working. At least more bugs that weren't noticed before could be fixed ;).

I'm tempted with getting a Pi but still sceptic it will be ok with my unoptimized code. Do you get roughly the same Girder reaction times as with a standard PC?

Yoggi
September 18th, 2016, 03:22 PM
Hi,

At the moment I am not running much on my Raspberry Pi 3. When it comes to turning on the lights with your plugin I would say that it is as quick as running on windows.

I run Raspbian (jessie) without starting the Desktop GUI, so only Girders backend is running on the pi. I can also mention that I run node-red on the same Pi as the Girder backend to simulate my networked TV(i emulate the TVs response to volume change, power on/off commands with node-red), and this also works without noticeable delay.

If you can come up with a test I would be happy to try it out for you. Maybe a script that dose something that can be measured (a script entered directly in the Windows frontend or a script on the Pis sd card).

One thing that I find that can be slow is for Girders backend to show up when I want to connect the frontend on windows to the backend (on the Pi) but this might be network related. I have the same "problem" with netremote, but when connected I have no problems with speed.

hoox
October 4th, 2016, 03:26 PM
Thanks Yoggi, with your findings I could more easily setup an EnOcean Pi. It is using the ttyS0 port of the Pi 3. Apparently we can use "dmesg | grep tty" to confirm that the ports are not used by the console after editing /boot/cmdline.txt. So far it works perfectly fine.
I was a bit confused with where and which Girder settings had to be moved, then added in the update a gml file that could help with that and how to modify the BaseID to avoid a new learning process on the receivers.