FS20 AS4 not switching with FHEM

Begonnen von mflammia1, 02 Januar 2015, 14:41:14

Vorheriges Thema - Nächstes Thema

mflammia1

Hi There,

Wondered if anyone has had any experience getting a FS20 AS4 working with a Raspberry Pi using a Busware CC1101 transceiver, http://shop.busware.de/product_info.php/products_id/97.

I have this working fine with MAX eq3 TVR's and wall thermastats. I can control them and they are reporting fine but just can not get this FS20 device to work.

Have followed the instructions here http://fhem.de/HOWTO.html, under the section 'Configuring receivers (actors)', but putting in the define lamp1 FS20 1234 56, and pressing the button on the FS20 until it flashes and hitting on/off in FHEM but it just will not sync.

Appreciate any help.

Many thanks

ph1959de

From your description it looks like you are using a CUL as interface between Fhem and your devices.

Please look at the details of your CUL device ... most likely it will show you that it is running in rfmode=MAX. Though a CUL is able to handle different protocols even at different frequencies it can only handle one at a time. Bottom line: running CUL in MAX mode processes only devices that talk MAX! protocol.

Please have a look at the System Overview and try to understand what is/would be required to support your current environment.

Kind regards, Peter
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

mflammia1

#2
You where spot on, I had no idea about all the different types, just thought the frequency was common - thanks for the information....

I changed it from MAX to SlowRF and it started working - well kind of. On the FS20 the light now stops flashing after you toggle the FHEM switch, but the process of actually remote switching is really hit and miss. There doesn't seem any pattern to it but I've only got it to remotely operate a few times (NEW NOTE: I seem to be able to toggle if I wait 30secs between switching). Elements of my config look like this:

define CUL_0 CUL /dev/ttyAMA0@38400 1034
attr CUL_0 rfmode SlowRF
#attr CUL_0 rfmode MAX
define cm CUL_MAX 123456
attr cm IODev CUL_0

define lamp1 FS20 5962 11
attr lamp1 IODev CUL_0
define lamp2 FS20 5962 12
attr lamp2 IODev CUL_0
define lamp3 FS20 5962 13
attr lamp3 IODev CUL_0
define lamp4 FS20 5962 14
attr lamp4 IODev CUL_0


2015.01.02 17:19:06 2: CUL_0: unknown message LOVF
2015.01.02 17:19:06 3: FS20 set lamp1 on
2015.01.02 17:19:06 2: CUL_0: unknown message LOVF
2015.01.02 17:19:09 3: FS20 set lamp1 off
2015.01.02 17:19:09 2: CUL_0: unknown message LOVF
2015.01.02 17:19:11 3: FS20 set lamp2 off
2015.01.02 17:19:11 2: CUL_0: unknown message LOVF
2015.01.02 17:19:12 3: FS20 set lamp3 off
2015.01.02 17:19:12 2: CUL_0: unknown message LOVF
2015.01.02 17:19:13 3: FS20 set lamp4 off
2015.01.02 17:19:13 2: CUL_0: unknown message LOVF
2015.01.02 17:19:15 3: FS20 set lamp1 on
2015.01.02 17:19:15 2: CUL_0: unknown message LOVF
2015.01.02 17:19:16 3: FS20 set lamp2 on
2015.01.02 17:19:44 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 27, but we need 113. Waiting 86 seconds.
2015.01.02 17:19:49 3: FS20 set lamp1 off
2015.01.02 17:19:51 3: FS20 set lamp2 off
2015.01.02 17:19:51 2: CUL_0: unknown message LOVF
2015.01.02 17:21:10 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 92, but we need 113. Waiting 21 seconds.
2015.01.02 17:21:38 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 6, but we need 113. Waiting 107 seconds.
2015.01.02 17:21:40 3: CUL_0: Unknown code Z0C1504420F78D80DDEB30026DD, help me!
2015.01.02 17:21:40 3: CUL_0: Unknown code Z0E1502020DDEB30F78D80001090026, help me!
2015.01.02 17:22:10 3: CUL_0: Unknown code Z0C1404420F78A40DDFFD002CE3, help me!
2015.01.02 17:22:11 3: CUL_0: Unknown code Z0E1402020DDFFD0F78A4000109002C, help me!
2015.01.02 17:23:19 3: CUL_0: Unknown code Z0C2104420F79110DE06C00AE00, help me!
2015.01.02 17:23:19 3: CUL_0: Unknown code Z0E2102020DE06C0F7911000109002E, help me!
2015.01.02 17:23:26 3: CUL_0: Unknown code Z0C0204420EBF2B0D301A002DFC, help me!
2015.01.02 17:23:26 3: CUL_0: Unknown code Z0E0202020D301A0EBF2B000109002D, help me!


When it works you just see the log message of lamp on or off without the message

CUL_0: unknown message LOVF

Also, that is a major a problem for me trying to run both the devices. The idea is that I use the MAX TVR's to independently call for heat from the boiler by using the FS20 to turn the boiler on and off - any ideas how to get around that.

Many thanks in advance.

ph1959de

The results look (at least partially) strange.

Did you shutdown/restart Fhem after changing the rfmode of the CUL?

Zitat von: mflammia1 am 02 Januar 2015, 18:34:42
CUL_0: unknown message LOVF
See LOVF (you may have to ask Google or similar to translate that page) ... as an explanation for one part of that message.

What surprises me (and doesn't match the picture) is the
CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 27, but we need 113. Waiting 86 seconds. part of your log file. This seems to indicate that you are still running your CUL in MAX mode (and have exceeded the transfer limit for that protocol).

Peter
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

mflammia1

Ok, so I rebooted, the only reason I hadn't was because the change seemed to work instantly.

The problem (intermittent switching, LOVF Messages and not enough credits) was still there after a reboot for about 20 mins the seems to have stopped and I no longer get any of those message and it is remote toggling instantly!

Still getting these messages though:

2015.01.02 20:30:25 2: CUL_MAX_SendQueueHandler: Missing ack from 0f78a4 for 0f9f04031234560f78a4000f02141e55
2015.01.02 20:30:40 3: CUL_0: Unknown code Z0C5704420F78D80DDEB30027E0, help me!
2015.01.02 20:30:40 3: CUL_0: Unknown code Z0E5702020DDEB30F78D80001090027, help me!
2015.01.02 20:30:48 2: CUL_MAX_SendQueueHandler: Missing ack from 0ddffd for 0f4204031234560ddffd000f02141e6c
2015.01.02 20:31:19 3: CUL_0: Unknown code Z0C5604420F78A40DDFFD002CDE, help me!
2015.01.02 20:31:19 3: CUL_0: Unknown code Z0E5602020DDFFD0F78A4000109002C, help me!
2015.01.02 20:32:19 3: CUL_0: Unknown code Z0C6304420F79110DE06C0032FF, help me!
2015.01.02 20:32:19 3: CUL_0: Unknown code Z0E6302020DE06C0F79110001090032, help me!
2015.01.02 20:32:25 3: CUL_0: Unknown code Z0C4404420EBF2B0D301A002DFE, help me!
2015.01.02 20:32:25 3: CUL_0: Unknown code Z0E4402020D301A0EBF2B000109002D, help me!
2015.01.02 20:32:57 3: CUL_0: Unknown code Z0C4F04420F79390DDFDE0026C6, help me!


So questions I have left, sorry, each fix seems to surface another issue or something I need to understand.

Any idea what the Unknown code is, how it maybe possible to use MAX and FS20 together (perhaps switching between two), or would I need another CUL, and why I would be getting credits on my MAX devices (perhaps I need to decrease polling time)?

Thanks for being so hopeful in the meantime.

Regards,

Martin

ph1959de

Martin,

not sure, what your configuration currently looks like. If you don't have too many definitions yet, it might make sense to start over with a fresh configuration, as you still seem to have a mixture of conflicting stuff.

Not yet asked, but at least useful to know: what version of Fhem are you using (execute command "version" from the command field and it will give you the versions of all modules that you currently have in use).

If the following is still "in place":
define CUL_0 CUL /dev/ttyAMA0@38400 1034
attr CUL_0 rfmode SlowRF
#attr CUL_0 rfmode MAX
define cm CUL_MAX 123456
attr cm IODev CUL_0

you probably should delete (or disable) device "cm", as this looks like MAX using your CUL which is in "FS20-Mode" SlowRF. I would attribute the "Unknow code" messages to this definition.

Using a single CUL for MAX and FS20 as far as I know is not recommended at all. I know of the possibility to use FS20 and IT (i.e. 868 and 433 MHz) "in parallel" but would always prefer a dedicated interface component per protocol.

Regards,
Peter


Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

mflammia1

Hi Peter,

Thanks again for posting back and for your patients with probably what seem fundamental questions, for an obvious newbie :)

Heres the output to version, I did update it not so long ago:

# $Id: fhem.pl 7124 2014-12-05 07:10:20Z rudolfkoenig $
# $Id: 00_CUL.pm 6980 2014-11-15 13:06:08Z rudolfkoenig $
# $Id: 14_CUL_MAX.pm 7067 2014-11-26 19:49:23Z mgehre $
# $Id: 01_FHEMWEB.pm 7176 2014-12-09 19:11:36Z rudolfkoenig $
# $Id: 10_FS20.pm 7070 2014-11-27 12:45:34Z rudolfkoenig $
# $Id: 92_FileLog.pm 7135 2014-12-05 21:11:17Z rudolfkoenig $
# $Id: 10_MAX.pm 7068 2014-11-26 19:50:04Z mgehre $
# $Id: 99_SUNRISE_EL.pm 6765 2014-10-14 18:24:29Z rudolfkoenig $
# $Id: 98_SVG.pm 7075 2014-11-27 20:59:58Z rudolfkoenig $
# $Id: 99_Utils.pm 6660 2014-10-03 06:35:43Z rudolfkoenig $
# $Id: 98_XmlList.pm 2895 2013-03-11 19:48:01Z rudolfkoenig $
# $Id: 98_autocreate.pm 6505 2014-09-06 12:24:48Z rudolfkoenig $
# $Id: 98_dummy.pm 4934 2014-02-15 08:23:12Z rudolfkoenig $
# $Id: 91_eventTypes.pm 6792 2014-10-19 16:03:13Z rudolfkoenig $
# $Id: 91_notify.pm 7135 2014-12-05 21:11:17Z rudolfkoenig $
# $Id: 98_telnet.pm 6611 2014-09-24 07:48:32Z rudolfkoenig $


You where right about the additional comment for the cm device, that has now stopped the messages.

Well Ive learnt a very fundamental thing that may seem obvious, but hopefully a trap no ones else will fall into... and that is, although FHEM is extremely versatile and on the surface looks like it can drive most things the different protocols for all the manufacturers ties its use to them specifically!

My vision was that I could use FHEM to drive all my home automation from a single interface, but what I should have done first was reference the 'System Overview' and been a little more choosy on the hardware, like for example, instead of using MAX I should have used 'SlowRF' products in order to give me a more versatile and complete home automation hardware selection.

Would you suggest I've worded that right, meant absolutely as no offence or blame of FHEM (which is brilliant by the way) or any of the hardware, but purely my lack of knowledge.

So again, this leads me to some more basic questions I'm sure:

1) If I am using MAX, then I assume I can also use HomeMatic devices seeing as these use the same modulation, frequency and modulation rate?
2) Could I get around this by using the something like the MAX Cube, and use IP instead.
3) Is there any other way to get around my problem of having MAX RF devices but still being able to use FHEM to control other home automation devices. Perhaps I'm just limited to MAX and HomeMatic, perhaps I can use an IP Cube, perhaps I will only be able to add IP devices, have you heard of LightWaveRF, could I use any of their products?

I know your time and support is free and I'm asking a lot of questions, but its much appreciated - nice to simply have a conversation with someone in the know :)

Cheers,

Martin

ph1959de

Zitat von: mflammia1 am 04 Januar 2015, 00:36:35
Would you suggest I've worded that right, meant absolutely as no offence or blame of FHEM (which is brilliant by the way) or any of the hardware, but purely my lack of knowledge.
This is perfectly describing your situation ... and why you ran into it.

Zitat von: mflammia1 am 04 Januar 2015, 00:36:35
So again, this leads me to some more basic questions I'm sure:

1) If I am using MAX, then I assume I can also use HomeMatic devices seeing as these use the same modulation, frequency and modulation rate?
Given the fact that the HomeMatic USB Interface costs around 30€ "only", I would not want to spend any effort to share these protocols over one transceiver. Technically, I don't know, whether HM and MAX! can "coexist" on a single interface.
Zitat von: mflammia1 am 04 Januar 2015, 00:36:35
2) Could I get around this by using the something like the MAX Cube, and use IP instead.
I don't know too much about MAX!, so can't comment on this.
Zitat von: mflammia1 am 04 Januar 2015, 00:36:35
3) Is there any other way to get around my problem of having MAX RF devices but still being able to use FHEM to control other home automation devices. Perhaps I'm just limited to MAX and HomeMatic, perhaps I can use an IP Cube, perhaps I will only be able to add IP devices, have you heard of LightWaveRF, could I use any of their products?
I would recommend to go back to "planning" with not-mixing-protocol as one major target. Multi-protocol support of a single interface component (best/only example: rfMode=SlowRF), as far as I can tell, in Fhem is available, where technically possible AND one or more of the developers pursuing this.
Zitat von: mflammia1 am 04 Januar 2015, 00:36:35
I know your time and support is free and I'm asking a lot of questions, but its much appreciated - nice to simply have a conversation with someone in the know :)
Well, I'm a (quite some time by now) user of Fhem only as well, never wrote a module but tried to give the wiki documentation some structure. As far as mixing of systems is concerned, you can see from my tagline what I'm using ... and that's what I may be able to help with/comment on based on own experiences.

Asking questions is ok, as long - like you do - newcomers (but not only newcomers) are willing to read, follow hints and/or advices and do their "own part of the job", not only "demand support".

Kind regards,
Peter

Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"