|
RF Connectivity
|
|
02-26-2017, 08:28 AM
the protocol is RFXMeter
RFXCom supports itm you just need to enable,, i think rf10 protocol there each message has a specific id - which you can configure in the config tool, for each type of data and the value is multiplied by 100 
02-26-2017, 10:25 AM
Yes I have the protocol enabled and I can see messages like this in RFXmngr:
Code: Packettype = RFXMeterBut in my home automation server (FHEM) I get the raw hex messages which looks like this: 0x0a710000867600017ae870 I am looking for information on how to decode that, please. I could not find specifications for protocol "RFXMeter". Thanks!
02-26-2017, 12:05 PM
Here is the spec, but i was expecting that RFXCom would provide the data you see parsed = in some way to FHEM.. at least for Domoticz it works this way, you only assign a sensor type to the data you get from RFXCom
Here is the code https://github.com/vlast3k/vESPrino-firm...t.cpp#L115 And this is the spec RFXMeter RF data format. Message length 48 bits (decimal) Code: | Byte 0 | Byte 1 | Byte 2 | Byte 3 | Byte 4 | Byte 5 |2 bytes address. Byte 2 = byte 1 with the complement of the upper nibble (bit 7-4). This way max 256 metering modules can be used. Counter value for an RFXPwr module measures with an accuracy of 0.001kWh and thus a value from 0 to 16777.215 kWh. Packet type: 0000 normal data packet 0001 new interval time set. Byte 2 0x01 30 seconds 0x02 1 minute 0x04 6 minutes (RFXPower = 5 minutes) 0x08 12 minutes (RFXPower = 10 minutes) 0x10 15 minutes 0x20 30 minutes 0x40 45 minutes 0x80 60 minutes 0010 calibrate value in <counter value> in µsec. 0011 new address set 0100 counter value reset to zero 1011 counter value set 1100 set interval mode within 5 seconds 1101 calibration mode within 5 seconds 1110 set address mode within 5 seconds 1111 identification packet Byte 2 = firmware version 0x00 – 0x3F = RFXPower 0x40 – 0x7F = RFU 0x80 – 0xBF = RFU 0xC0 – 0xFF = RFXMeter Byte 3 = interval time (see packet type 0001) 4 bits parity. This is the complement of: byte 0 bit 7-4 + byte 0 bit 3-0 + byte 1 bit 7-4 + byte 1 bit 3-0 + byte 2 bit 7-4 + byte 2 bit 3-0 + byte 3 bit 7-4 + byte 3 bit 3-0 + byte 4 bit 7-4 + byte 4 bit 3-0 + byte 5 bit 7-4
02-26-2017, 03:36 PM
(02-26-2017, 12:05 PM)admin Wrote: Here is the spec, but i was expecting that RFXCom would provide the data you see parsed = in some way to FHEM.. at least for Domoticz it works this way, you only assign a sensor type to the data you get from RFXCom I guess the RFXMeter protocol is supported in Domoticz already then. In FHEM it is not (at least not for the RfxTrx433). Thanks, I will look into that!
02-27-2017, 01:56 PM
ahhh
 yeah - now when i was looking at some posts in google, this seems to be the case.
02-27-2017, 04:00 PM
I am onto implementing that for FHEM.
One thing I noticed and could not understand. Usually the periodic data message for the CO2 sensor looks like this (there is some sort of envelope from the RFX, so the message length is 10 bytes instead of the raw 6 byte message you are sending): 0a 7100 b2 8676 00 01c070 69 sensor ID (0x86 -> 134) 3 byte value So these are regular data messages with the default sensor ID of 134. But when booting the device I always get a message like this but only once: 0a 7100 9a 42b2 00 0003e8 69 So a message from a sensor ID 0x42 with a value of exactly 1000 (0x3e8). Its always 1000. Could you please explain what this is?
02-28-2017, 03:37 AM
great
 you've decoded them allthis first message is a test message sent once during boot, i used it to quickly test if the devices are fine let's hope now also the issue with the jamming will turn to be a hardware one
03-02-2017, 10:25 PM
(02-28-2017, 03:37 AM)admin Wrote: this first message is a test message sent once during boot, i used it to quickly test if the devices are fine I have the normal messages now working reliably in FHEM, thats fine But it seems I was wrong about the other message type: In fact it is not only sent once on bootup but it is sent regularly (even quite often): Code: 2017.03.02 21:33:47.588 5: TRX: TRX_Read '0a7100cf42b2000003e879'Would it be possible to turn this message off in the sensor if it is not needed in regular operation? Thank you!
03-03-2017, 03:57 AM
aaahhh, indeed - this will happen in the case when the device goes to sleep, as after each sleep cycle it reboots and then goes through sending this
yeah.. i can fix it
04-19-2017, 05:04 PM
(This post was last modified: 04-19-2017, 05:07 PM by Christopher Wansing.)
(03-02-2017, 10:25 PM)vbs Wrote: I have the normal messages now working reliably in FHEM, thats fine Can you tell something more about the Fhem integration? I have a 433Mhz Cul and want to do the same thing you did. I am new to Fhem but already looked at quite a lot things and integrated some Intertechno(Pollin) outlets and a lot of Max! Heating thermostats. But I am totally new to integrating custom RF devices, which are not regulary supported by Fhem, despite I am really eager to learn it, because there are quite a few devices I could use this for. For example I also have cheap 433Mhz Lightswitches from Aliexpress throughout my apartement and want to get Fhem to recognize those, too. The current solution with a cheap RF Receiver and an RCSwitch based Python RFSniffer is quite unreliable, when I am using an emitter at the same time. Seems they are booth using the WiringPi library and that there are some cross complications(At least thats what I found on the internet till now) What I already know is how to record the raw pulses using an RTL-SDR and some basic knowledge about setting the CUL to a verbose mode 5 and that there are some codes to get the CUL sending raw messages to Fhem. What I dont know is how I am able to react on those or how I can write a script to process the data. Do I have to leave the Raw message state and verbose 5 or am I able to write a custom module, so that in the end fhem supports the device more natively? Because the I dont really want all the messages this generates in regular running mode. Would be very glad about at least some hints in the right direction, for getting this to work
|
|
« Next Oldest | Next Newest »
|
