ignore RFXX10REC devices

Begonnen von Guest, 03 Mai 2012, 21:57:05

Vorheriges Thema - Nächstes Thema

Guest

Originally posted by: <email address deleted>

Hi,

Is there a way to ignore RFXX10REC devices? In the documentation
there's no "ignore" attribute specified. Does someone have a tip /
trick to accomplish the same result (as using "ignore" for FS20
devices)?

Cheers,

Eeg.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

Originally posted by: <email address deleted>

Am Donnerstag, 3. Mai 2012 21:57:05 UTC+2 schrieb Superbert:
>
> Hi,
>
> Is there a way to ignore RFXX10REC devices? In the documentation
> there's no "ignore" attribute specified. Does someone have a tip /
> trick to accomplish the same result (as using "ignore" for FS20
> devices)?
>
>
There is already the attribute do_not_notify there (unfortunately
undocumented. This has to be done....).
Adding the ignore attribute is easy. I will probably check this into SVN
today.

Do an updatefhem tommorrow and it will probably be done and work.

If you want it earlier, just change line 70 in  43_RFXX10REC.pm to:
  $hash->{AttrList}  = "IODev ignore:1,0 do_not_notify:1,0
loglevel:0,1,2,3,4,5,6";

-- Willi

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

Originally posted by: <email address deleted>

Hi,

Thanks, I will have a look this weekend.

I do have another question: Do you know if it would be possible to
support the new KAKU (IT) protocol by modifying the RFXX10REC module?
I did already some investigation, but it's hard to find-out how it all
fits together...as far as I understand, the RFXCOM module determines
by a Regex which module to call. The new KAKU / IT protocol starts
with a different value (ASCII "), so this would have to be added to
the RFXCOM and then the received string should be analyzed in either a
new module or in RFXX10REC.

With "new" protocol I mean the devices that support automatic learning
(34 bits I think).

I did some debugging attempts with Eclipse & EPIC, but unfortunately
not successful yet (as the break-points / debugging doesn't work for
the modules...it works in fhem.pl however). I'll give it another go
with "Komodo" soon, see if I can find out how everything fits
together.

Cheers,

Eeg.

On 4 mei, 15:59, Willi wrote:
> Am Donnerstag, 3. Mai 2012 21:57:05 UTC+2 schrieb Superbert:
>
> > Hi,
>
> > Is there a way to ignore RFXX10REC devices? In the documentation
> > there's no "ignore" attribute specified. Does someone have a tip /
> > trick to accomplish the same result (as using "ignore" for FS20
> > devices)?
>
> There is already the attribute do_not_notify there (unfortunately
> undocumented. This has to be done....).
> Adding the ignore attribute is easy. I will probably check this into SVN
> today.
>
> Do an updatefhem tommorrow and it will probably be done and work.
>
> If you want it earlier, just change line 70 in  43_RFXX10REC.pm to:
>   $hash->{AttrList}  = "IODev ignore:1,0 do_not_notify:1,0
> loglevel:0,1,2,3,4,5,6";
>
> -- Willi

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

Originally posted by: <email address deleted>

Am Freitag, 4. Mai 2012 17:06:27 UTC+2 schrieb Superbert:
>
> I do have another question: Do you know if it would be possible to
> support the new KAKU (IT) protocol by modifying the RFXX10REC module?
> I did already some investigation, but it's hard to find-out how it all
> fits together...as far as I understand, the RFXCOM module determines
> by a Regex which module to call. The new KAKU / IT protocol starts
> with a different value (ASCII "), so this would have to be added to
> the RFXCOM and then the received string should be analyzed in either a
> new module or in RFXX10REC.
>
>
I do not know if the old RFXCOM receiver support this protocol. I general
my module can not support more than the protocols that the RFXCOM receiver
firmware supports.

Any protocols that are not known by my modules are logged to the FHEM
logfile.
There should be an output like

RFXELSE: bits=$bits num_bytes=$num_bytes hex=$msg
 
If there is such an output, please send these loggings.

If there is no such output that you can determine as KAKU protocol, we do
not have any chance.

-- Willi

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

Originally posted by: <email address deleted>

Hi,

to determine if you can really receive the KAKU protocol, I would suggest
that you use the
RFreceiver.exe program that came with your RFXCOM receiver and try it with
your KAKU devices.
If this works, tell me what are the bytes received and what the meaning is.

-- Willi

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

Originally posted by: <email address deleted>

Hello,

I have changed the modules used by RFXCOM and TRX to both allow the
attributes ignore and do_not_notify. Also I have added the attribute
"longids" for RFXCOM/OREGON. Default is to use longids for compatibility
purposes. There are also compatibility changes so that the output of RFXCOM
and TRX modules should be now the same.

See commandref.html for further details.

All is in the actual SVN. Thus you may get the update tomorrow via
updatefhem.

-- Willi

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com