Homeeasy HE830S

Begonnen von fruit, 12 November 2013, 17:51:31

Vorheriges Thema - Nächstes Thema

fruit

I've been running fhem on RPi with a MAX! Cube and 5 radiator thermostats for about a month, all working very well.

I have just obtained a Homeeasy HE830S, a 3 socket (UK) and remote pack. There doesn't seem to be any reference to it on this site so wondering if any other UK users may be have the same.

It will sometimes work under fhem but every command seems to cause the RFXTRX to disappear then reappear - I can control it with no problems under RFXmanager and AC. The command strings seem different but I haven't worked my way through it all yet - and I'm not very good at Perl!
Feel free to follow up in German if you prefer

Willi

You will be probably the first user with Homeeasy UK (which to my oppinion is different from Homeeasy EU).

Please tell us the output of the log files at the crash/reappear times.
Please do also tell how the devices are configured.

Regards

Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

fruit

Lucky me, it was the last set in the shop so I thought worth a try.

fhem autocreated the following for the first device, similar for the other two

define TRX_AC_000043b802 TRX_LIGHT AC 000043b802 light
attr TRX_AC_000043b802 comment Switch 1
attr TRX_AC_000043b802 room TRX_LIGHT
attr TRX_AC_000043b802 verbose 5
define TRX_HOMEEASY_0000400002 TRX_LIGHT HOMEEASY 0000400002 light
attr TRX_HOMEEASY_0000400002 comment Switch 1
attr TRX_HOMEEASY_0000400002 room TRX_LIGHT
attr TRX_HOMEEASY_0000400002 verbose 5
define TRX_ARC_N10 TRX_LIGHT ARC N10 light
attr TRX_ARC_N10 comment Switch 1
attr TRX_ARC_N10 room TRX_LIGHT
attr TRX_ARC_N10 verbose 5

Using RFXmngr I was able to turn on/off using the TRX_AC_ device, no success with the others:-
0B110010000043B802010F70
Packettype    = Lighting2
subtype       = AC
Sequence nbr  = 16
ID            = 00043B8
Unit          = 2
Command       = On
Signal level  = 7
0B110011000043B802000070
Packettype    = Lighting2
subtype       = AC
Sequence nbr  = 17
ID            = 00043B8[/quote]
Unit          = 2
Command       = Off
Signal level  = 7


fhem log reversed for the same device:-
2013.11.12 12:34:44 3: Setting RFXTRXUSB baudrate to 38400
2013.11.12 12:34:44 1: /dev/ttyUSB0 disconnected, waiting to reappear
2013.11.12 12:34:43 5: SW: 0B110000000043b802000000
2013.11.12 12:34:43 5: RFXTRXUSB sending 0B110000000043b802000000
2013.11.12 12:34:43 5: TRX_LIGHT_Set() lighting2 hexline=0B110000000043b802000000
2013.11.12 12:34:43 5: TRX_LIGHT_Set() lighting2 name=TRX_AC_000043b802 device_type=AC, deviceid=000043b802 command=off
2013.11.12 12:34:40 1: /dev/ttyUSB0 reappeared (RFXTRXUSB)
2013.11.12 12:34:40 3: Setting RFXTRXUSB baudrate to 38400
2013.11.12 12:34:40 1: /dev/ttyUSB0 disconnected, waiting to reappear
2013.11.12 12:34:39 5: SW: 0B110000000043b802010000
2013.11.12 12:34:39 5: RFXTRXUSB sending 0B110000000043b802010000
2013.11.12 12:34:39 5: TRX_LIGHT_Set() lighting2 hexline=0B110000000043b802010000
2013.11.12 12:34:39 5: TRX_LIGHT_Set() lighting2 name=TRX_AC_000043b802 device_type=AC, deviceid=000043b802 command=on
2013.11.12 12:33:48 1: /dev/ttyUSB0 reappeared (RFXTRXUSB)
2013.11.12 12:33:48 3: Setting RFXTRXUSB baudrate to 38400


There is an obvious difference between command sent if I am reading it correctly
0B110010000043B802010F70 to turn on with RFXmngr
0B110000000043b802010000 attempt to turn on with fhem

At times fhem will switch one or two of the three, a little later those may not work but another does. The reappered/disappeared happens at every attempt, RFXTRX is direct to RPi now. Confusing!

Is there anything else I should try and log? (There is nothing in any /var/log for the reappered/disappeared occurences.)
Feel free to follow up in German if you prefer

Willi

Hmm.

Try to change the
define TRX_AC_000043b802 TRX_LIGHT AC 000043b802 light

to
define TRX_AC_000043b802 TRX_LIGHT HOMEEASY 000043b802 light

This will use Homeeasy instead of AC which should be correct.

Not sure why there is a reconnect.....
Which Firmware version are you using on the RFXtrx433?

Just give it a try.

-- Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

fruit

#4
Thanks for the help.

That change doesn't work at all - but gives me a clearer idea of how fhem works. Changing back to AC gives me random success again.

I have lost the SW: loglines for most transactions this morning. Verbose 5 is set for the RFXTRX. Could that imply the RFXTRX is disappearing before the command is sent? Nothing at all relevant in /var/log/ still and nothing else new in fhem log.

I have tried both latest fw versions 69 and 169 on the RFXTRX. The earliest I have here are 67 and 167, earlier versions don't seem to be available. I will try those later and try the other protocols in RFXMngr again in case I missed something yesterday.

I am still a bit puzzled by the difference between

0B110010000043B802010F70 to turn on with RFXmngr
0B110000000043b802010000 attempt to turn on with fhem

Should I expect the bytes after deviceid to be the same for both for the same command? I haven't really worked out it's all put together yet.

Later:
I see those last bytes are not as relevant as I thought. On and off from RFXmngr today (switch 2)..
Lighting2 command:0B 11 00 37 00 00 43 B8 03 01 00 00   On
Lighting2 command:0B 11 00 38 00 00 43 B8 03 00 00 00   Off

I have now installed fw 67. The only working protocol in RFXmngr is AC, that works without fault, no issues with USB disappeared etc. but not sure where that may be logged in Windows.

There is no difference in fhem log between an on/off that works and one that doesn't.

Feel free to follow up in German if you prefer

Willi

Zitat von: fruit am 13 November 2013, 07:53:00
I am still a bit puzzled by the difference between

0B110010000043B802010F70 to turn on with RFXmngr
0B110000000043b802010000 attempt to turn on with fhem

This is why I have asked you to user HOMEEASY instead of AC.
0B11001 is Homeeasy and 0B11000 is AC. At least these bytes should be then the same,

The other difference 0F70 to 0000: This is strange as this does not comply to the SDK information I have from RFXCOM.

Would it be possible to get a screenshot what you specified on RFXmngr to generate this code?

Greetings

Willi

Could
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

fruit

I'm sorry, I pasted the command registered from the remote in RFXmngr not the RFXmngr generated command which would be
0B110033000043B802000700
for switch1 off (unit 2). I'm sure you are aware the 33 is sequence number, 7 the level - set as a test only.

Last bytes from the remote are 01 0F 70 on, 00 00 70 off
RFXmngr generated 01 00 00 and 00 00 00 respectively work OK.

I have checked again and the only working mode for this device in RFXmngr is AC.

I managed to lose my RPi from the network earlier, USB HD lead I think so had other things to think about for a while.


I have also acquired an HE330S, not quite the same as the HE830S and different remote. It's picked up by fhem but cannot be switched. Interestingly just using the remote triggers a '/dev/ttyUSB0 disconnected, waiting to reappear' message. Works fine in RFXmngr, AC mode again.

These are the only devices I have on the RFXTRX but I assume the constant disconnect, disappear, reappear messages should not happen in normal use. I am wondering if it's a driver/RPi issue so will try and set up fhem on a desktop and see if the same happens, at least I may be able to eliminate hardware.

I'll have a play around and see what I find. At least the remotes work ;)
Feel free to follow up in German if you prefer

fruit

#7
All is working correctly and repeatedly for both sets of devices on my desktop machine, basic fhem 5.5 install,
Debian Wheezy, 3.2.0-4-amd64, RFXTRX fw 67. All devices set at verbose 5, no disconnected, disappeared or reappeared in logs.

Sorry if I have wasted your time Willi, thanks for your help.

Not running well and not sure there is a way around it on Raspberry Pi
raspbian rpi 3.6.11+ #538, RFXTRX fw tried 67, 69, 169. This RPi is 'Made in China', there seem to be other reports in this forum of issues with other USB devices on at least some of these.

For the benefit of any UK users who may find this, both HomeEasy/Byron HE830S and HE330S sets should work correctly (but possibly not on RPi). HE830S devices have a teach/reset button, will survive power off. HE330S devices require re-teaching after power off - reset procedure is to power off for min. 55 seconds.

Sorry, I'm back yet again to add to this after further work on the HE830S switches.

Following an rpi-update on the RPi the disconnected/disappeared/reappeared messages in the logs have completely disappeared, the RFXTRX now logs as it did on my debian box and the original switches are all working as they should. I can only assume a firmware update has changed something, nothing else has been installed or updated over the course of these attempts other than regular fhem updates.

There is more though. I bought another set of cheap HE830S, all recognised correctly by fhem but only two out of three would switch. Same with RFXmngr this time. No differences in logs. After unplugging and resetting/teaching a number of times and leaving it unplugged for a while it finally started working. No idea what changed. Both RFXmngr and fhem commands same before and after. Seems some of these devices may be a little temperamental to start with. So far they are all still working. (I'm now running fw-69 but tried 67 and 68 for this last device, no obvious differences).
Feel free to follow up in German if you prefer

dowlix

I have some old Home Easy power sockets, and I've been using fhem for a couple of weeks now. With a RFXtrx433 connected to my Desktop PC (Debian Squeeze).

I'm glad that fruit has resolved his/her problem on the Raspberry Pi - when I have completed my testing and configuration, I intend to move over to a Pi (which I already have, I don't know which version but I bought it very soon after reelase).

Anyway, the point of my post is really to say that today I discovered that my old Home Easy sockets don't work when I set the protocol to "HOMEEASY". The devices were auto created as "AC" and when I changed them today to "HOMEEASY" they stopped working. I do have another Home Easy socket that I haven't yet tested with fhem; I am sure that it is newer (white HE300W controller as opposed to "old" black / grey HE312S). I can see that the products shown on the home easy website are different again to the devices that I currently own.

This is the stuff that is working ONLY as "AC" and NOT as "HOMEEASY": http://www.amazon.co.uk/Home-Remote-Control-Socket-Silver/dp/B003EGMFA0

This is the second control that I have available, I guess it came with a different socket, one that I haven't seen whilst browsing today: http://beta.maplin.co.uk/p/home-easy-5-way-remote-control-n10jq

I have much to learn concerning fhem; today I managed to send myself an e-mail and I am thrilled at all the possibilities.

fruit

My HE830S and HE330S are all working well now using the AC protocol. I really can't explain my early issues other than a possible RPi firmware upgrade but they do seem temperamental initially.

The learn with the remotes generates a lot of spurious TRX_ARC and TRX_HomeEasy signals I think resulting in the creation of those devices in fhem as well as the TRX_AC. I've deleted those now as I don't intend using the remotes again if I can help it.

Obviously I can't say it would be the same for other HE sockets. My remotes are labelled HE300 for the HE830S and HE312Sv2 for the HE330S if it's any help.

There do seem to be many versions of HE sockets around. I've noticed the Maplin devices too but they and B&Q seem to be replacing their HE stock with Lightwave stuff. Mine came from the latter, end of line bin. The amazon image looks the same as my HE330S.

I had thought of getting rid of the HE330S in view of the re-learn after power-on but this doesn't seem to be the case. Although they flash in learn mode at start they still respond to fhem commands as expected even after unplugging overnight - I'll test for longer.

I'd guess you may have a 256k RPi if it is early, can't see any references in the forum re. performance. Expect you will have fun with fhem, I have so far - and a lot of head scratching!
Feel free to follow up in German if you prefer