Contents
Introduction
culfw is an open source (GPL V2) firmware for different busware.de
gadgets.
These gadgets all feature a CC1101 transceiver and an Atmel
MCU, which is used for low-power wireless communication in the 868 or 433 MHz
band. See busware.de for details and on how
to buy them.
Supported device types:
- The CUL (Cc1101 Usb Light)
Following models are known:
- CUL_V1 (AT90USB162: 0.5 kByte RAM, 16 kByte Program memory, 0.5 kByte EEPROM)
- CUL_V2 (AT90USB162: 0.5 kByte RAM, 16 kByte Program memory, 0.5 kByte EEPROM)
- CUL_V3 (ATMEGA32U4: 2.5 kByte RAM, 32 kByte Program memory, 1.0 kByte EEPROM)
- CUL_V4 (ATMEGA32U2: 1.0 kByte RAM, 32 kByte Program memory, 1.0 kByte EEPROM)
There is also a 433MHz version of the CUL available.
- The CUR (Cc1101 Usb Remote) is a device with following features: CC1101 /
AT90USB646 / 16Mbit flash / 128x128 color display / 5-way jogdial / Battery.
It is a prototype device, and it has extensive culfw support.
- The CUN (Cc110x Usb Network) is a device with following features: CC1101 /
AT90USB1287 / Ethernet interface / 16Mbit flash / 256Kbit SRAM / MicroSD
- The CSM (Cc110x Serial Module) talks via a serial line (1.8-3.3V) instead
of USB with the host system. CC1101 / ATMEGA324/644/1284(P) used in: CUNO,
TuxRadio
- The CUNO (Cc110x Usb Network Onewire) is a device with following features:
CSM == CC1101+ATMega m644/m1284 cpu / Ethernet interface w/ PoE /
ACM-USB bridge / OneWire Bus-Master DS2482 / MicroSD
- The Raspberry Pi Addon Board (rpiaddon) by Damian Melson, a device with the following
features: CSM = CC1101+ATMega m644v/OneWire Bus-Master DS2482/BMP085 braometric pressure
sensor/TSL2561 luminosity sensor/128x64 pixel TFT display/IR-receiver.
See Add-On-Board and
the corresponding forum thread.
This firmware makes it possible to use these devices with fhem. Currently the
following RF protocols are supported:
- FS20
- FHT
- EM
- KS300/S300TH
- HMS
- ESA
- ASKSIN (aka BidCos(R))
- basic OneWire Protocol through the DS4282 (CUNO only)
- UNIRoll
In the culfw package there are pre-built .hex files ready for flashing the
device, for the casual user there is no need to install the compiler suite.
Note that especially the CUL_V2 .hex files do not contain all features due to
the restricted program memory available on this hardware.
Thanks to the MyUSB project (http://www.fourwalledcubicle.com/MyUSB.php, ) the
device/firmware combination confirms to the Universal Serial Bus Communication
Device Class Abstract Control Model (USB CDC ACM) specification, so it can be
used out of the box with a lot of operating systems.
Compiling and Flashing
Prerequisites
You'll need following packets to flash (i.e. install) the firmware:
- CUL/CUN/CUR
- dfu-programmer on Linux or OSX
- flip on Windows
- CUNO/CSM/rpiaddon
- avrdude
If you want to modify the firmware:
- avr-libc
- binutils-avr
- gcc-avr
Ubuntu: "apt-get install avr-libc" will install all three packages
OSX: use CrossPack-AVR, and the dfu-programmer from the ports package.
Windows: avrdude is part of WINAVR.
Compile (optional)
Change into your device directory (e.g. culf/Devices/CUL)
Type "make", which will output text like:
Install / Flash the firmware
Change into your device directory (e.g. Devices/CUL)
- CUL/CUN: Insert the USB-Stick while pressing the micro-switch on the back:
a USB device "03eb:2ffa Atmel Corp." should appear.
Now execute "make usbprogram", which will output text like:
dfu-programmer at90usb162 erase
dfu-programmer at90usb162 flash CUL.hex
Validating...
6312 bytes used (51.37%)
dfu-programmer at90usb162 start
The last command will reset the device, a new USB device should appear:
"03eb:204b Atmel Corp.". If not try to reinsert the CUL without pressing
the micro-switch.
- CUNO:
configure the COM-Port/serial device by which CUNO will be connected
(/dev/ttyACM0, or COMx) in the file Devices/CUNO/makefile, look for
AVRDUDE_PORT
insert the USB-Cable while pressing the micro-switch on the back.
execute "make usbprogram"
- TuxRadio: see README in Devices/TuxRadio directory
Quick Test
USB Device @ OS/X
You'll see a device /dev/cu.usbmodemf...., depending on the USB port on the
host.
Start a terminal window and connect to the device with "screen /dev/cu.usbmodemf....".
You can temirnate screen with <Ctrl><A> :quit<return>
USB Device @ Linux
Hopefully you see a device /dev/ttyACM0 (if you use a newer kernel, which
loads the cdc_acm kernel module), or a /dev/ttyUSB0 (if your kernel uses
usbserial). For usbserial kernel you may need to add the module options
"usbserial vendor=0x03eb product=0x204b" to modprobe.conf.
Connect to the device e.g. with "screen /dev/ttyACM0".
CUNO: Connect to the device e.g. with "screen /dev/ttyACM0@38400".
USB Device @ Windows
Install a virtual COM port, use MyUSB_USBtoSerial.inf from the docs
directory. Locate the COM-port in the device manager shown as
"USB Virtual Serial Port (COMx)". Start Hyperterminal, open a connection
to COMx 9600,8,n,1.
For CUNO: Install a virtual COM port, use MCP2200.inf from the docs
directory. Locate the COM-port in the device manager shown as
"USB Virtual Serial Port (COMx)". Start Hyperterminal, open a connection
to COMx 38400,8,n,1.
CUN/CUNO: Connect the device to a network with a DHCP server, and then telnet to
the assigned address with "telnet <ip-adress> 2323"
After you connected to the device with screen, hyperterminal or telnet:
Type "V". The string "V 1..." should appear. Type X21 to
enable the RF data reporting.
Protocol Part 1 (culfw configuration)
The data is ASCII (i.e. human readable) with cr/nl as a message terminator.
The first byte is the command (case significant), the rest ist command
dependent, usually a hex string, case insignificant. Commands are _not_
echoed. Following commands are available (alphabetic list):
A<func>[<hex>]
AskSin (aka BidCOS (R)) mode. <func> is one of:
- r
enable AskSin (10kbit/s) reception. Note: only AskSin messages will be
received in this mode. Data is reported in hex. If bit 4 was set in
previous X cmd (i.e. X10) reported data is binary. Messages sent
with "s" will be sent as normal AskSin messages.
- R
enable AskSin firmware-update (100kbit/s) reception. Note: only AskSin
firmware-update messages will be received in this mode. Data is reported
in hex. If bit 4 was set in previous X cmd (i.e. X10) reported data is
binary. Messages sent with "s" will be sent as firmware-update messages.
- s
Send out an AskSin message. <hex> is a hex string of the following
form: llnnccttssssssddddddpp...
ll - length
nn - msg counter
cc - control byte
tt - msg type
ss - sender address (3byte)
dd - destination address (3byte - 000000 for broadcast)
pp - payload...
- x
Disable AskSin mode. To enable reception of FS20 messages, an "X21" or
similar is needed.
a<XX>[<YY>]
(CUR only)
If no YY is specified:
Display the battery state:
XX = 01 raw reading
XX = 00 reading transformed into %, taking nonlinearity into account
If both XX and YY is specified (CURV3 only):
XX = 00 Charge with 500mA (YY=01) or 100mA (YY=00)
XX = 01 Disable USB charging (YY=01) or enable it (YY=00)
B<hex>
Reboot device.
If <hex> is not 00 enter bootloader mode (for flashing the device see the
flashing section above)
b<cmd><data>
Wireless M-Bus:
- r<mode>
start receiving messages. <mode> bust be either s or t for desired mode
- s<data>
send data (tbd)
returns always the actual receiving mode
C<reg>
<reg> is a (two digit) hex number: return the value of the cc1101
register. <reg>=99 dumps the first 48 registers.
Example: C35 -> C35 = 0x0D / 13
c<hex>
(CUR/CUN )
Read/set the clock: either the RTC chip (CUR only) or the internal NTP
counter (CUN only). If hex is 01, then display the date, if it is 02 the
time, if it is 03, then both date and time. If the length of hex is 6,
then the RTC will be set to YYMMDDHHmmSS. Data is written BCD, i.e
December is written as 12 and not as 0C. The RTC version of the clock
may be set partially: if hex is 6 characters long (converted to 3 bytes)
then only the time part will be set. This is not applicable to NTP.
D<cmd><data>
(TuxRadio) 3x16 character LCD display access, where <cmd> is:
- c
clear display: Dc
- t<pos><text>
write text with <pos> two digits hex: Dt10Hallo (beginning of line 2)
- b<value>
set contrast to <value> (two hex digits): Db33
- C<byte>
send native controlbye - see display manual
d<hex>data
(CUR only)
Choose the sub-function with the first two bytes (hex):
- FF: LCD control, the next 3 bytes (6 chars) are:
- LCD on (01) / on+cls (02) / off (00) / don't change (FF)
- contrast: set directly (00-FE) / read from eeprom (FC) /
increase (FE) / decrease (FD) / don't change (FF)
- brightness: set directly (00-FE) / read from eeprom (FC) /
increase (FE) / decrease (FD) / don't change (FF)
- 00: Set the title to the string following the 00
- 01-08: Set the "body" lines 01-08 the the text
- 09/0A: Insert a new line at the bottom/top of the screen,
scrolling the rest.
E<x>
(CUN only) eth debugging
- c
Print out the currently configured IP & MAC address.
The IP address may be different from what you configured with Wia
if DHCP is enabled. 0.0.0.0 is shown if no IP address is set, e.g.
when DHCP is enabled but the network cable is unplugged or CUN
could not get an IP address over LAN. Note that the IP address
that you configured with Wia is disregarded if DHCP is enabled.
- d
increase the debug level. Meaning of the levels
1: application debugging, e.g. the NTP module will display the time
2: print ETH header (mac adress + ETH frametype)
3: dump whole ethernet packet.
- i
Reinitialize the ethernet subsystem, restart DHCP & NTP
- n
Request an NTP update
e
EEPROM / factory reset.
resets all eeprom values. e causes a reboot to activate all changes.
"ex" will reset the eeprom values without a reboot, this is for internal
use only.
F<hex>
Send out an FS20 message. <hex> is a hex string of the following form:
hhhhaacc or hhhhaaccee, where
- hhhh is the FS20 housecode,
- aa is the FS20 device address,
- cc is the FS20 command
- ee is the FS20 timespec. Note that cc must have the extension bit set.
Example: F12340111
f<type>[<data>]
"fast" (250kBaud) rf txmit via CC1101 packet handling.
First switch both devices to fastrf mode with "fr", then send data:
fs<data>, e.g. fsHallo
Reset to "SlowRF": fx, followed by X21
It can be used to "sniff" RFR packets
GssNnprHHLLhhllDDDD...
Send raw data, only if HAS_RAWSEND is enabled.
- Everything after the command G is hex.
- ss Number of sync bits. Sync is always 0, followed by exactly one
1-bit.
- N Number of data bytes (exclusive the last byte if it is not complete)
- n incomplete last-byte: LSB-Position (7=first bit) after which no
more bits will be transferred (7-n = number of bits in the last
Databyte)
- p Number of ms pause between repeats
- r Number of repeats (e.g. FS20: 3)
- HH High-Time for the 0-bit, Unit is 16us (!)
- LL Low- Time for the 0-bit, Unit is 16us (!)
- hh High-Time for the 1-bit, Unit is 16us (!)
- ll Low- Time for the 1-bit, Unit is 16us (!)
- DDDDD... Databytes
Use X67 and X1E to find your rawsend-pattern.
H<func>[<hex>]
HM485 mode. <func> is one of:
- ?
report statistics:
- SEND: messages sent
- RECV: messages received
- FE: UART frame errors
- PE: UART parity errors
- OV: UART overruns
- CRC: checksum errors
- DATA: message structure errros
- SIZE: messages too large
- s
Send out a HM485 message. <hex> is a hex string of the following
form: ddddddddccsssssssspp...
The length byte (after the header) and the CRC are automatically
added.
- dd - destination address (4 byte, FFFFFFFF broadcast)
- cc - control byte
- ss - sender address (4 byte, 00000001 controller)
- pp - payload...
I<cmd><data> - Infrared Rx/Tx
<cmd> is one of:
- r<mode>
enables IR reception (mode: 00-off / 01-on / 02-on, no repeating messages)
i<func>
InterTechno (R) mode.
<func> is one of:
- t<dez>
Sets the time in us (microseconds) for a single wave-puls
typical values are: 360-470
Default: 420 (good for most InterTechno compatible Devices)
- sr<dez>
Sets the number of repetition for the InterTechno Command.
The command needs to be sent several times, as the receivers are
comparing several receptions.
Default: 6
Note: Some discounter versions are toggling too much, then reduce to ~4
- s<AAAAAAAAAAAA> Note: 12-Address/Data Bits
Sends an InterTechno command
A-Address/Data Bit is Tri-State
0 /1/F (float) (see Notes at the end)
M<hex>
Send out an EM message. <hex> is a hex string of the following form:
ttaacc111122223333
- tt:type 01=EM-1000s, 02=EM-100-EM, 03=1000GZ
- aa:address, depending on the type above 01:01-04, 02:05-08, 03:09-12
- cc:counter, will be incremented by one for each message
- 1111: cumulated value
- 2222: last value (Not set for type 2)
- 3333: top value (Not set for type 2)
Example: M02054A140000000000
N<func>
Native RF mode.
This mode does not use any packet or CRC features of CC1101. It just looks for
preamble and given sync word and returns a fixed amount of received data.
This is meant for compatibility to RFM12B-based protocols. Checking, decoding
and processing of this raw received data is up to a higher software level.
<func> is one of:
- r<mode>
enables reception of datagrams. The following modes are known:
- 1 - LaCrosse/IT+ 17.241 kbps
- 2 - LaCrosse/IT+ 9.579 kbps
- 3 - PCA 301 - 868.9500MHz 6.631kbps
Data is returned with prefix:
N<mode><payload> i.e.
N019746372630AAAA0000101A7F
N019CF6397D410021A6554ADF1A
- x
disables reception
Just "N" returns active mode.
l<hex>
Set the led mode.
- 00: Set LED off
- 01: Set LED on
- 02: The LED will blink once a second
O<func> OneWire Command-Set
(CUNO only)
<func> is one of the following:
- i - Initialize OneWire Sub-System; Reset HMS-Emulation & Timers
- R<func> Reset Routines:
- b - Reset OneWire Bus; Returns:
- 0 - No Device connected
- 1 - One or more Devices connected
- 2 - Short detected on OneWire Bus
- m - Reset OneWire Master (DS2482-Chip); Returns:
- OK - Chip Resetted
- FAILED I2C - DS2482 Chip can't be reached via I2C internal Bus
- c - Returns list of found RomCodes for OneWire Devices
(based on OneWire FullSearch, performed during boot, or with Of-Command)
Output: 1:aabbccddeeffgghh where a-h are Hex-Values: 64Bit Address
2:aabbccddeeffgghh
- w<func> Write Routines
- b<hex> - Write one BIT to the OneWire Bus; <hex>: 00, or >00 otherwise
- B<hex> - Write one BYTE to the OneWire Bus; <hex>:dd Hex-Value of Data
- r<func> Read Routines
- b - Read one BIT from the OneWire Bus; Return: <hex>: 00, or 01 otherwise
- B - Read one BYTE from the OneWire Bus; Return: <hex>:dd Hex-Value of Data
- m<hex> - MatchRom Code to select Device; <hex>:64-Bit Address in 8xHEX
- H<func> HMS Emulation Routines for Temp-Sensors (DS18B20 & DS18S20)
- o - Toggle HMS-Emulation on/off; Returns: ON / OFF
Based on found RomCodes an HMS Emulation will be done for
OW-Temp-Sensors DS18B20 & DS18S20
- t<dec> - Set Time-Interval for HMS-emulated Reporting
<dec>: Seconds in decimal: 0-255
default: 120s
- C<func> Sensor-Conversion Routines
- s - Start Asynchronous Conversion for a selected Sensor (MatchRom)
- r - Checks if an asynchronous conversion is still running; Returns:
- 1 - Conversion still running
- 0 - Conversion finished
- a - Checks if Conversion Slot for ALL Sensors is still running;
This is used for HMS-Emulation, as all Sensors go to conversion
at the same time; Returns:
- 1 - Conversion still running
- 0 - Conversion finished
- f - Start a new RomCode Full Search on the OW-Bus
o<func> OBIS Command-Set
(CUNO2 with hardware patch and IR-head only)
<func> is one of the following:
- r - read most recent telegram
- a<seconds> - set automatic reading of telegrams
P<hex><filename>
(CUR only)
Display a picture. The hex part consists of 4 bytes (x,y,w,h), and the
file contains the data in a 12bit per pixel format. Use
fonts/pgm2fourbit.pl with the raw option to convert raw PPM files into
the needed format, and tools/cur_file.pl to upload the file
q
Terminate the TCP/IP session (CUN only)
R<AA> or R<AAAA>
Read eeprom (i.e. "saved configuration") byte. Arguments: one or two
byte hex address <AA> or <AAAA>
Adress-Slots:
- 0x00 - 0x01
Eeprom magic bytes
- 0x02 - 0x2A
Configuration registers foe "SlowRF" as described in the "Table 37: "SPI Address
space" of the CC1101 datasheet (Version SWRS061C). Note: all EEPROM
Values have an offset of 2.
- 0x2B - 0x32
CC1101 PA Table (8 bytes).
See fncollection.h for more details.
Example: R00 -> 63
Additional CUN-only commands:
- Rim - MAC Address
- Rid - DHCP enabled flag
- Ria - IPV4 Address
- Rig - IPV4 gateway
- Rin - IPV4 network mask
- Rip - tcplink port
- RiN - NTP sever
- Rio - GMT offset
r<filename>
(CUR/CUN)
Display the file <filename> from the builtin 2MB flash. First the length
of the file, (hex 8 byte+nl) is written to the output, then the body of
the file. Use "." as filename to get a listing of the current files with
length.
Use the program cur_file from the tools directory to read a file, e.g.:
perl cur_file.pl -r MENU /dev/ttyACM0
NOTE: No fhem/screen must be connected to the CUR while reading/writing
s<hex>
(CUR only)
sleeptime. Switch everything off after <hex> seconds of joystick
inactivity. An instant sleep is achieved by pressing the joystick.
00 disables sleep.
If the CUR is connected via USB then only the display will be switched
off.
THHHHxxxxxx
FHT80b/FHT8v/FHT80TF commands
FHT80b syntax: THHHHCCAA[CCAA[CCAA...]]
FHT8v syntax: THHHHCCOOAA
FHT80TF syntax: THHHHABCC
- HHHH FHT80b (or 8v) housecode
- CC Command (for FHT80TF: 0x0C - Sync, 0x0F - Finish, 0x01 - open, 0x02 - closed)
- OO Command origin (CUL:77 or FHT:67)
- AA Argument
- AB Addressbyte
Store the message in the FHT80b or FHT8v buffer, and communicate with the
corresponding 80b/8v when the timeslot arrives. 8v commands are specified
by setting HHHH to one of the "own" housecodes. See also the FHT_8v
section below.
Special control commands:
- T01<HHHH>
Set the "own" housecode to HHHH. The first byte will be used as the FHZ
code in in FHT80b mode. This command will also clear all buffers.
Note: if HHHH is 0000, then FHT80b communication is switched off.
- T01
Return the own housecode (hex)
- T02
Return the FHT80b buffer. FHT80b commands are queued in the internal
buffer, which has place for 14 to 31 messages.
A command is removed from the buffer after CUL has received the
acknowledgement from FHT80b.
A short form (only the destination, without the content) is returned if
T0200 is specified, this mode is intended for FHTs connected via RFR.
- T03
Return the size of the remaining FHT80b buffer (bytes, hex).
- T10
Return the FHT8v buffer. There is one value per 8v address.
- T11
Return the time till the next 8v timeslot (seconds, hex)
- T12
Return the FHT80TF buffer. There is one value per TF address.
t
Output the time since boot (uptime). The output is a hex number,
resolution is 1/125 sec. An overflow occures every 397 days.
U<hex>
Send out an UNIRoll message. <hex> is a hex string of the following form:
ggggdc, where
- gggg is the UNIRoll group address,
- d is the UNIRoll device address,
- c is the UNIRoll command (b - down, d - stop, e - up)
Example: U12340b
u<data>
RF_ROUTER functionality
A CUL can work as a router, by sending/receiving data to/from a remote
CUL via RF. So it is possible to extend the range by plugging additional
CULs into the socket, and configure them to send their data to the
local (i.e. PC-connected) CUL.
- u (without parameter)
Display the own and the router id, both one byte hex.
- uiRRBB
Set the own/rfr id, and the base id (the id of the CUL connected to
fhem).
If RR is not 00, the RF_ROUTER functionality is enabled.
If BB is not 00, the RF reception is enabled at start (X21) and all
received messages (FS20/FHT/etc) are relayed to the CUL with id BB.
Messages arrive on the base CUL (with id BB) with the prefix BBRRU see
the exampe below.
- uRRBB<message>
Send <message> to the CUL with ID <RR> from the sender BB.
<message> will be executed as a local command on the remote CUL.
Answers will be sent (only!) to the configured router and not the
BB id specified in this command.
- ud (if compiled with RFR_DEBUG)
display the current ticks, and the ticks for the scheduled rf_router
answer. Used to check if rf_router is working
- us (if compiled with RFR_DEBUG)
Statistics: Number of sent messages in categories. The categories are:
F.T.E.K.H.x.#, x beeing the rest and # the number of delayed
transmissions due to current rf reception. All numbers are 16bit
counters.
Example:
- ui0601 (configure remote CUL)
- ui0100 (configure local CUL)
- u0601V -> 0106UV 1.34 CUL868
- u0601C35 -> 0106UC35 = 0D / 13
V
Print the firmware version.
Example: V -> V 1.30 CUL868
VH
Print the hardware version on CUL_V3 and CUL_V4
v<func>[<hex>]
Honeywell EvoHome/EvoTouch mode.
<func> is one of:
- l
Listen for EvoHome messages.
Only EvoHome messages with a valid checksum will be returned in this mode.
Messages are reported on receipt as vr<hex> with the valid checksum byte removed.
- d
Listen for EvoHome messages as above, but also report aborted receives as v!<code>[<hex>].
This extra information can be useful for debug purpose.
Codes include:
Interference related
- F - Framing error, where received data doesn't decode to 1start-8data-1stop at 38,400bps
- M - Manchester coding error in received data
- C - Checksum error over completed message
Firmware problem
- L - Message exceed expected maximum length
- O - Overrun, where a second data byte arrived before the ISR processing the first was able to complete
- s<hex>
Send out an EvoHome message. No checking is performed on sent data, but a valid checksum
is automatically added.
-
Disable EvoHome reception.
Responses
- va - Successful acknowledgement to request
- vb - Attempt to send whilst device busy receiving a message (small timing window, just retry)
- v? - Unknown command
W<AA><DD> or W<AAAA><DD>
Write eeprom (i.e configuration) byte. Arguments: one or two-byte hex
address <AAAA> followed by one byte hex data <DD>.
See R above for address (AAAA) explanation.
Example: W1D06
Additional CUN-only commands:
- Wim - MAC Address
- Wid - DHCP enabled flag
- Wia - IPV4 Address
- Wig - IPV4 gateway
- Win - IPV4 network mask
- Wip - tcplink port
- WiN - NTP sever
- Wio - GMT offset
Notes:
- Factory reset: use DHCP, port 2323, NTP-Server = Router, GMT offset:0
- Everything becomes active only after a reboot.
- MAC adress is written as hex, with optional semicolon
- IP4 adresses are written in decimal with dot separator
- port is written in decimal
- if the NTP server is 0.0.0.0 (default), then the router is used as
an NTP server.
- the GMT offset is specified as a hex number, and is a signed value:
ff==-1, fe==-2, etc
- factory reset will re-initialize this data, with a unique MAC address
- If DHCP is enabled, the left (orange RX/TX) led blinks till a valid
DHCP adress is received.
Example:
Wim01:02:03:04:05:06
Wia192.168.0.1
Wio02
w<length><filename>
(CUR/CUN)
write the file named <filename> to the 2MB onboard flash. Length is hex,
8 bytes. The command must be followed by length bytes of data, which
will be written to the local file. If length is FFFFFFFF, then the file
will be deleted.
Use the program cur_file.pl from the tools directory to write a file,
e.g.:
perl cur_file.pl -w MENU /dev/ttyACM0
NOTE: _NO_ fhem/screen must be connected to the CUR while reading/writing
Special control commands for the CUL:
- w01 enables event logging to the file Syslog.0, w00 disables it.
Factory reset is disabled, as writing to the log is relatively slow,
and the CUN/CUR may skip RF messages.
- wformat will reformat the flash (== writes the superblock)
X<RR>
Enable data reporting for SlowRF (i.e. 1kHz data rate)
<RR> is a one-byte hex value, with following bits (bit 0 is the LSB bit):
- Bit 0: Report known messages (parity & checksum ok), with type prefix.
- Bit 1: Report each of the (repeated) packets of a message
- Bit 2: Report detailed data, even with wrong parity / checksum.
- Bit 3: Monitor mode: output an r on a risings edge and 'f' on a falling
edge. Output a '.' at the end of the message (no signal for
4msec).
- Bit 4: Timing: in monitor mode output one additional byte of the
internal microsecond timer, divided by 16. This is binary!
- Bit 5: RSSI: report RSSI value as an additional HEX byte after digested
data or as a separate byte if Bit 3 is set too.
- Bit 6: Report FHT protocol messages (ack, etc)
- Bit 7: CUL/CUN: Report raw RSSI data (a==weak ... p==strong signal)
CUR: Grafic representation: dark==weak ... light == stong signal
Note: 00 disables radio reception, any other value initializes the radio
chip and enables reception. Default is 00: do not report anything, radio
chip is uninitialized.
Example: X01 (normal reporting, no RSSI) or X67 (debugging)
If <RR> is not specified, report the current value and the available
time for sending RF (in 10 ms units)
x<pp> Change the (EEPROM) PA tables (power amplification for RF sending)
<pp> is a one-byte hex value, valid values are 00 to 09, with following
values: the first 5 is -10/-5/0/5/10 dBm with PA ramping, the next 5 is
the same without PA ramping. If the value is outside this spec, then the
5dBm variant (03) will be used.
Notes:
- after changing the value (in the EEPROM) an X command (X21) will be
necessary to write the EEPROM changes to the CC1101.
- The default CUL_V2 firmware has no PA ramping compiled in (see board.h)
- The CUL itself cannot receive data sent with PA ramping, FS devices
have no problem receiving such data.
Example: x03
Y<func>
Somfy RTS/Simu Hz (R) mode. <func> is one of:
- t<dez>
Sets the time in us (microseconds) for a single symbol
Typical values are: 1200-1300
Default: 1240 (According to the patent it should be 1208, but this works better)
- r<dez>
Sets the number of repetitions of a Somfy RTS frame.
If the receiver is far away from the sender, increasing this number may help reception.
Default: 6
- s
Send out a Somfy command. <hex> is a hex string of the following form: KKC0RRRRAAAAAA
KK - Encryption key
C - Command (1 = My, 2 = Up, 4 = Down, 8 = Prog)
0 - Checksum (set to 0, is calculated automatically)
RRRR - Rolling code
AAAAAA - Address (= remote channel)
Z<func>[<hex>]
MORITZ (aka MAX!) mode. <func> is one of:
- r
enable MORITZ reception. Note: only MORITZ messages will be received in
this mode. Data is reported in hex. If bit 4 was set in previous X cmd
(i.e. X10) reported data is binary.
- s
Send out an MORITZ message. <hex> is a hex string of the following
form: llnnccttssssssddddddpp...
ll - length
nn - msg counter
cc - control byte
tt - msg type
ss - sender address (3byte)
dd - destination address (3byte - 000000 for broadcast)
pp - payload...
- x
Disable MORITZ mode. To enable reception of FS20 messages, an "X21" or
similar is needed.
Unknown commands
Prints the "help", the list of supported commands
Example:
z
? (z is unknown) Use one of B C F R T V W X e f l t x
Protocol Part 2 (radio messages)
The CUL reports following data (as a HEX string, uppercase):
- For FS20:
Fhhhhaacc or Fhhhhaaccee, explanation see the command F above
- For FHT:
ThhhhNNNNNN
As this part is quite complex, for an explanation look into the 11_FHT.pm or 09_CUL_FHTTK.pm (FHT80TF) fhem module.
- For EM:
Ettaacc111122223333
- tt:type 01=EM-1000s, 02=EM-100-EM, 03=1000GZ
- aa:address, depending on the type above 01:01-04, 02:05-08, 03:09-12
- cc:counter, will be incremented by one for each message
- 1111: cumulated value
- 2222: last value (Not set for type 2)
- 3333: top value (Not set for type 2)
- For KS300:
KFFTTTHWHWWRRFR
Data must be read backwards
- For S300TH:
KaaTTHTHH
Data must be read backwards
- For HMS:
Hxxxxxxxxxxxx
- For native RF-Mode:
N<mode><payload>
- For ESA2000:
Sxxxxxxxxxxxx
- For Hoermann Garage door openers:
Rxxxxx
Note: this protocol is not really understood.
- For AskSin/MORITZ:
allnnccttssssssddddddpp...
Allnnccttssssssddddddpp...
- ll - length
- nn - msg counter
- cc - control byte
- tt - msg type
- ss - sender address
- dd - destination address
- pp - payload
(for binary data lower case 'a' is prepended - MORITZ messages are structured same but letter 'Z'/'z' is prepended)
- For OBIS:
oESY5Q3DA1004 V3.03||1-0:0.0.0*255(1124001569)|....
Frame '/' - '!' has been removed. CRLF within telegram translates to '|'
- For TX2/TX3 (see http://www.f6fbb.org/domo/sensors/tx3_th.php):
tLTAAXYZXY
- L - length
- T - type counter
- AA - address
- XYZ - data
- XY - data, repeated
- For HM485
Hddddccsssspp...
- dd - destination address (32 bit)
- cc - control byte
- ss - sender address (32 bit)
- pp - payload
- For UNIRoll
Uggggdc
- gg - group address address (16 bit)
- d - device address (4 bit)
- c - command (4 bit)
- For Wireless M-Bus
bllddddd...
- ll - number of mbus packet data bytes to follow
- dddd - mbus packet data
If bit 3 in the X command is set, then report raw data, even if it has a
wrong checksum or parity. The format is:
p State zhi zlo ohi olo NSync NByte Nbit [RSSI] NNNN
- State Internal state of the state machine
- zhi avg. high-time of the zero bit
- zlo avg. low- time of the zero bit
- ohi avg. high-time of the one bit
- olo avg. low- time of the one bit
- Nsync Number of 0 sync bits
- Nbyte Number of whole bytes received
- Nbit Number of bits (last partial byte)
- RSSI RSSI, if the RSSI bit is set, see X cmd
- NNNN Raw data with parity/checksum, without sync.
FHT_8v
The 80b is designed to control multiple 8v's in one room. It is possible to
have up to 8 different 8v values, but only one value is sent every 2 minutes,
it takes 16 minutes to set 8 different values.
We optimize culfw to control 8v's in different rooms, for this purpose we
need to update them faster (idea and first implementation by Alexander).
For this purpose up to eight different "own" house codes are used: The first
valve gets the house code directly. Subsequent valves get the house code
increased by 0x0100. Values for each valve are sent directly one after the
other, but only once. The device ID is forced be be 0x01 at each valve.
Setup a connection between the cul and an 8v:
- T011234 (set HC to 1234)
Press the 8v button for 3 seconds, it will beep twice
- T123400A610 (sets value for first valve to 6%)
- T1234012f00 (pairs first valve, 8v will beep once, antenna will blink till
first reception of the offset value entered before)
- T10 (check 8v buffer, should tell 00:2610)
- T11 (check 8v countdown timer)
- T123400A620 (change value for first valve to 13%)
- T133400A610 (set value for second valve to 6%. Pair as described before)
- T10 (check 8v buffer, should tell 00:2620 01:2610)
Sync consumes a lot of rf-time and it can be easily disturbed, so we try to
reduce the "normal" 2 minute (115+x) interval by remembering the last
interval in higher level software, and schedule a sync with a smaller runtime
at the correct time. Note: the argument must be odd, and it is measured in
0.5 seconds.
- T1234002C21 (Sync for 0x21 == dec 33 == 15 seconds)
FHT80TF
The 80b is designed to handle up to 4 FHT80TF window sensors. A housecode of
FHT80TF starts at the first byte above 0x69.
To setup one or more window sensors, use the commands below. Set the FHT80b in
syncing mode for sensors and start with a sync, followed by a finished command.
The default value after this procedure is window closed (0x02). Now, you are be
able to set the right value. Use the following list of commands:
- T8630A00C - start sync
- T8630A00F - finished sync
- T8630A001 - window open
- T8630A002 - window closed
- T011234 (set HC to 1234) - clear the buffers
- T12 check FHT80TF buffer, could tell 00:8630A001, if empty -> N/A
(8630A0 -> example address of FHT80TF)
CUR Menu
To define a menu on the CUR, follow this HOWTO:
- create a fhem xml-list with
fhem.pl fhemhost:7072 xmllist > fhem.xmllist
- convert the template and the fhem listing into a CUR MENU file:
perl xmllist2curmenu.pl fhem.xmllist CUR.menu.template > MENU
- write the MENU file to the CUR:
perl cur_file.pl -w MENU /dev/ttyACM0
NOTE: The CUR must be in the X00 mode (default after reboot), and no
fhem/screen should be connected to it.
- switch the CUR display on by pressing the joystick.
- To have a nice logo on the first screen, upload it to the CUR:
cd fonts
perl ../tools/cur_file.pl -w house2_58x60 /dev/ttyACM0
InterTechno(R) - 433.92 Mhz
The basic protocol is a 12-Bit Tri-State Protocol. As the transceivers
for this protocol can handle 3 states the different versions of IT-Switches
are putting those Bits either to Ground(0), to VCC (1) or leaving them
open(Float).
The original InterTechno(R) Switch knows ONLY 0 & F, but many
discounter variants are also using 1 & F or 1 & 0 or even all
three states 0/1/F.
The DIP-Switches on the Device determines the address (usually the
first 8-10 Bits) and the last two bits are for switching.
The original IT-Switch has 8-Bit Address (0/F) then 0F (Bit 9/10)
and 11 (ON) or 10 (OFF) for bits 11/12.
IT uses Codes for Addresses: (Addresses are LSB..MSB)
House Device
A 0000 1 0000
B F000 2 F000
C 0F00 3 0F00
.. .. ..
N F0FF 14 F0FF
O 0FFF 15 0FFF
P FFFF 16 FFFF
For Switching Bit 11/12 are needed (either 11/10 or 11/00) depending
on the Brand of the Switch.
Bit 9/10 are either part of a non-IT Address (discounter) or are fixed
(0F for IT, 00/11 or any combination for other brands)
The Wave consists of a Base-Peak of around 400us but as most of them
are using cheap crystals it may vary (therefore it can be adjusted).
420us seems to fit the most so far.
CC1100 settings
See the culf/cc1100.h or the official PDF from TI for details.
- Change receiver sensitivity / target amplitude
- AGCCTRL2 (0x1B), bits 2:0, target amplitude:
0:24dB, 1:27dB, 2:30dB, 3:33dB, 4:36dB, 5:38dB, 6:40dB, 7:42dB
Default value: C1B -> 07 (42dB).
- AGCCTRL0 (0x1D), bits 1:0, decision boundery
0:4dB, 1:8dB, 2:12dB, 3:16dB
Default value: C1D -> 91 (8db)
Example: W1D06
Notes:
- fhem users can set these values with "set CUL rAmpl 42; set CUL sens 8"
- R/W address (EEPROM) for the FS20/SlowRF Communication is = CC1101
address+2, for the FastRF Communication is CC1101 address+55. See
fncollection.h for other values.
- Change frequency
FREQ2(0D), FREQ1(0E), FREQ0(0F), Fosc = 26MHz
Fcarrier = Fosc/65536*(FREQ2.FREQ1.FREQ0)
Example: W0F21, W1065, W11E8 (868.35MHz)
W0F21, W1062, W1176 (868.00MHz)
Note: fhem users can set it with "set CUL freq 868.3" (868.3 is default)
- Change channel bandwidth
MDMCFG4 (10). CHANBW_E (bits 7:6), CHANBW_M (bits 5:4)
BWchannel = Fosc/(8 * (4+CHANBW_M) * 2 ^ CHANBW_E)
Example: W1255 (325KHz, default)
W1245 (406KHz)
W1235 (464KHz)
Note: fhem users can set it with "set CUL bWidth 325"
- Read-Only-Registers:
RSSI: : C34 -> 217 (217-256-74 = -113 dBm)
MARCSTATE: C35 -> 01 (Idle), 13 (RX)
Sample CUN(O) setup
This section describes how to setup CUN for ethernet access with the following
settings:
DCHP client: off
IP address/netmask: 192.168.31.126/255.255.255.0
Gateway: 192.168.31.1
NTP server: 192.168.31.2
Time zone offset: GMT+2
Connect CUN to your PC via USB. On Linux a device /dev/ttyACM0 will appear (on
subsequent experiments, the device may be named /dev/ttyACM1, /dev/ttyACM2 and
so forth). Use screen /dev/ttyACM1 to talk to CUN and screen /dev/ttyACM1@38400
for CUNO. Enter the following commands:
V output version, e.g. V 1.39 CUN
Wid00 disable DHCP
Rid
Wia192.168.31.126 set IP address
Ria
Wig192.168.31.1 set gateway
Rig
Win255.255.255.0 set netmask
Rin
WiN192.168.31.2 set NTP server
RiN
Wio02 set time zone offset
Rio
En request time from NTP server
c03 show date and timeslot
The Ri commands read back what you've just written to eeprom.
Reboot CUN and connect to it via telnet 192.168.31.126 2323.
Misc. notes
- 1% LIMIT
The firmware respects the 1% limit for this band, i.e. only 160 FS20
messages per hour will be sent. See the second number returned by the "X"
command for the remaining send-time (in 10 ms units). This time is updated
once a second.
- Repeat-filter
The FS20 protocol sends each message 3 times. The firmware filters optionally
(See Command X bit 1) repeated messages.
- CUNO via USB
The USB-Bridge of CUNO operates on 38400 Baud. This means, that you have to
assign this speed to the port in your host OS.
Typically you use CUNO via /dev/ttyACM0@38400.
This sets the speed to 38400 on the port.
TODO/Known BUGS
- Setting the FHT time sometimes changes the date too
- FS20 dim commands should not repeat.