Open dmit2k opened 5 months ago
Hi @dmit2k
thanks for the questions and your ideas on how to improve the project. If there is something that can be improved, I am generally open to do it. To be honest, I have only one Marley fan at my Workshop and I use this it stays in the same operation mode.
Regarding the device address, I could be a good idea to add some additional output of all the device addresses the could be found. Additional I could image to add some WebUI for control and setup parameters as well.
I have done something similar at this project: https://github.com/dewenni/ESP_Buderus_KM271 Maybe I could add something similar to this project.
In this case it would be necessary to have someone for testing and feedback.
I have also to check how I can further test things, because I have implemented this as an addition to an existing ESP Project. So I don't have a separate ESP with only this software. This is something that I have to build up again for testing. Lets see, maybe I find some time within the next days.
regards Sven
hanks for your prompt response!
Once again, THANK YOU for your project. It kick-started my brain in the right direction as I had no idea where to start integrating my Marley into my smart home (HomeAssistant based). Despite my long experience with ESPs and smart homes, I was unaware of the CC1101 module and how to begin decoding the Marley protocol.
Following your example, I assembled my CC1101 and Wemos D1 Mini modules, checked your marley.cpp code, and successfully deployed an ESPHome firmware to listen to RF and debug Marley communications.
Here’s what I found: while your protocol decompilation is almost 100% correct, there are some intriguing points that suggest there might be some kind of unit discovery within the protocol. After adding a binary dump, here’s what I observed.
A typical status datagram looks like this:
[02:43:31][D][rc_switch:079]: Received HEX code: 0xFAA06B [02:43:31][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=4 data='111110101010000001101011' [02:44:41][D][rc_switch:079]: Received HEX code: 0xFAA06A [02:44:41][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=4 data='111110101010000001101010'
Periodically, the device sends datagrams like this:
[02:44:31][D][rc_switch:077]: Received HEX code: 0xFAA000 [02:44:31][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=4 data='11111010101000000'
I think my device ID is '11111010101000000' (padded with zeroes 0xFAA0), and yours is 0x8EA0 (not 0x8EA06).
I'm not sure what this additional '6' means, but it does not appear to be part of the device ID. The rest of the datagram matches the operation codes you have discovered 100%.
@dewenni a bit of offtopic, but by the way, you have closed my 5 years old bounty call for Marley integration into smarthome, which is 10 litres of beer :) Please PM me how can I send the EUR equivalent to you :)
I'm glad to hear that the project is useful and that you like it.
I would suggest, that I add the DeviceID to the mqtt topics and create a separate topic for each device. This could be created automatically based on the received messages from the marley devices.
esp_marley
status
"deviceID_1"
"deviceID_2"
cmd
"deviceID_1"
"deviceID_2"
I could also try to use mqtt discovery for Home Assistant. In that case, the Device would be automatically available as mqtt device in Home Assistant. There is a device class fan that could be fit also to this device. The class has options for
I have to build up a little test system for me to go forward, because at the moment I have implemented the code into a existing project and I don't want to use this as a development project and also the hardware is used for other things. But I have a additional ESP and also a CC1101 to do that.
regarding the beer :-) maybe I will add something in the readme with the next release to have the possibility to "by me a coffee or beer" For now, if you like the project, please rate it with a ⭐️ - that could help others to find this project easier.
Hi Sven,
please find my comments below:
I would suggest, that I add the DeviceID to the mqtt topics and create a separate topic for each device. This could be created automatically based on the received messages from the marley devices.
This is exactly what I was thinking of. I arrived at a similar device status topic structure with separate mode, speed, and direction sub-topics while experimenting with my own ESPHome code:
- cmd
- "deviceID_1"
- power
- summer
- interval
What do you mean by "interval"? If this sub-topic is supposed to send commands to the device, we are limited to "+" and "-" incremental commands only, which I find a bit inconvenient for smart home server usage.
However, I have a strong feeling there could be some "hidden" commands with "unused" bytes (like 0x8EA063, 0x8EA065, 0x8EA069 in your case).
I have a very basic CC1101 module without an antenna, so I'm using just a piece of wire. I'm not sure if this is the reason, but I'm unable to control my Marley unit—it does not react to the commands I'm sending out. Maybe you can try these on your own device?
I could also try to use mqtt discovery for Home Assistant. In that case, the Device would be automatically available as mqtt device in Home Assistant.
Yea! This is exactly what I was thinking as well! It's a nice feature! But we should have a way to limit this auto-discovery somehow. While experimenting with my device, I was surprised to catch some unknown devices from my neighbors. This makes me think that the RF protocol used in our units is not unique to Marley but is a standard RF switch widely used in household appliances.
We should be able to filter out "alien" devices to avoid their uncontrolled addition to Homeassistant... Not sure how to do this yet, but the ESP module can store some data when powered off and across reboots. We can implement a kind of "discovery" mode, such as pressing a remote button 10 times in a row to make the module store this ID as valid and introduce it to Home Assistant.
There is a device class fan that could be fit also to this device. The class has options for
- payload on/off
- direction (should fit for in/out)
- oscillation (in our case it could be the interval setting and status?)
- percentage (here we have to reduce the 0..100% into slow, middle, fast)
Agree. For our specific speed modes, we can use percentages of 0%, 33%, 66%, and 100%.
We could probably assign the ventilation modes "recuperation" and "summer" to "oscillation".
I have to build up a little test system for me to go forward, because at the moment I have implemented the code into a existing project and I don't want to use this as a development project and also the hardware is used for other things. But I have an additional ESP and also a CC1101 to do that.
I have ordered another CC1101 module with a built-in antenna, but it will take a while to arrive. Still, I'm ready to help you with any kind of research or testing in my home lab with the module I have on hand now. I just need to learn the ESP development IDE you are using. I have experience with Tasmota and ESPHome only. BTW, it's a good idea - maybe I have RF sending issues just because of my own wrong code, not antenna...
regarding the beer :-) maybe I will add something in the readme with the next release to have the possibility to "by me a coffee or beer" For now, if you like the project, please rate it with a ⭐️ - that could help others to find this project easier.
Already starred, waiting for donation link! ))
What do you mean by "interval"? If this sub-topic is supposed to send commands to the device, we are limited to "+" and "-" incremental commands only, which I find a bit inconvenient for smart home server usage.
The mode where the direction changes every x seconds. I called it "interval" and you call it "recuperation" So we have in general two modes "interval / recuperation" and the "summer" mode. We could say that:
regarding storage of parameters. I have used LittleFS FileSystem in the past to stare config parameters in a config file. That could be done in the background and don't need any additional handling for the users.
I am asking myself if it could be better to switch to a ESP32 instead of the ESP8266. The ESP32 is more powerful and would be better if we want to add a Webserver for configuration and optional control interface like in my other project => https://github.com/dewenni/ESP_Buderus_KM271
Would this be also ok for you? This is one of the modules that is similar to the wemos D1 ESP32-D1-Mini or the cheaper one ESP32-S2
We could say that:
- oscillation = true = "interval / recuperation"
- oscillation = false = "summer"
Sounds reasonable.
regarding storage of parameters. I have used LittleFS FileSystem in the past to stare config parameters in a config file. That could be done in the background and don't need any additional handling for the users.
Rely on you, never played with permanent storage on ESPs before.
I am asking myself if it could be better to switch to a ESP32 instead of the ESP8266. The ESP32 is more powerful and would be better if we want to add a Webserver for configuration and optional control interface like in my other project => https://github.com/dewenni/ESP_Buderus_KM271
Would this be also ok for you? This is one of the modules that is similar to the wemos D1 https://www.az-delivery.de/products/esp32-d1-mini
I have ordered a couple of such esp32-dq-mini modules along with cc1101 with antennas, still 2-3 weeks to arrive.
But I also have one of the older esp32 dev boards laying around, it will not be a problem to use it. But should we really do this? Simple web interfaces work pretty well on esp8266 (look at Tasmota for example), and for controlling the Marley unit only it will be an overkill I think.
But this still may be reasonable if we are going to equip the ESP with an air quality, humidity or CO2 sensor and implement some scheduling or extended logics based on sensors directly on-chip, which may be helpful for people not using smart home servers...
So what about having a basic esp8266 version without web server (just a kind of blind learning mode by using remote buttons) first? Then it will not be difficult to recompile for esp32 once needed for extended features.
I guess many people have esp8266 modules on hands, supporting it will make the project more open for wider audience. But you decide, that are just my thoughts.
A Webserver to configure some basic stuff like WiFi credentials would be useful. And then we can also configure the devices with alias names and so on.
I tried to run the same web server like in my other project and that was not working. The 8266 is crashed a lot. But I think I can use also "a smaller version" that works for the 8266. lets see...
JFYI: I have successfully installed and configured PlatformIO then recompiled your project with my own device ID and credentials. And now RF transmitting works perfectly! :)
That means I just did something wrong in my own code and antenna is working OK. So I can participate in further testing if you need.
@dmit2k how many maley fan´s do you have?
@dmit2k how many maley fan´s do you have?
only one at the moment, but wanted to add another one as in dual mode they do synchronize with each other and work more effectively
Greetings @dewenni !
Really great project that I was looking for the very long time!
I have a spare D1-mini board and just bought the cc1101 module to give it a try.
But looking at the code I don't see any kind of Marley device address discovery. You just define MARLEY_ADR in the header file and that's it. But how can I get it for my own device?
Another way would be just listen for all Marley-like packets, extract the device address part and publish each message to MQTT under it's own device address subtree. The same way we can get destination address from MQTT to send out commands.
The Marley fans definitely have individual and a kind of unique device addresses, just because there may be several devices in a house and even two in one room.
Are you still interested in this project to move it a bit forward?.. Unfortunately, I'm not good enough as CPP programmer to make the mods myself.
Regards, Dmit