Ramses II 868MHz communicatie via evofw3 en ramses_rf

[vliegnerd]

Veel verwarming en ventilatie systemen gebruiken het Honeywell Ramses II protocol dat op 868 MHz berichten verstuurt en ontvangt.

Dit protocol wordt o.a. door Honeywell Evohome, Itho Daalderop (WTW, spider thermostaten) en Orcon (WTW) gebruikt. (En waarschijnlijk andere apparaten waarvan Airios de OEM hardware/electronica levert)

Hardware:

HGI-80

Voor communicatie/besturing is de HGI80 gateway op de markt gebracht. De HGI80 is een RF naar USB bridge. Deze HGI80 is ondermeer geleverd als onderdeel van de Itho spider gateway:

(afbeelding uit de review van de spider gateway)

De HGI80 ontvangt de 868 MHz RF berichten en schrijft ze op de USB seriële poort:

code:

---  I --- 37:17xxxx 32:13xxxx --:------ 22F1 003 000107  # RF15 zet Orcon WTW op stand 1

De HGI80 is helaas slecht verkrijgbaar, kan vervangen worden door een kloon. Meestal een arduino/atmega microcontroller met CC1101 chip.

evofw3

De software die op deze kloon draait is evofw3: https://github.com/ghoti57/evofw3
Opties:

• SSM-D2 een atmega32u4 met cc1101. De referentie hardware gemaakt en verkocht door de maker van evofw3. Betrouwbaar maar slecht verkrijgbaar en duur (importheffing uit VK).
• Nanocul 868MHz - V1 en V2 is/was een arduino nano (atmega328p). evofw3 draait alleen op de 16MHz atmega328p en de cc1101 gebruikt 3v3. Daarom zijn de meeste nanoculs 8MHz waarop evofw3 slecht werkt. Ontvangen werkt redelijk. Zenden bijna niet. Nanocul v3 met een atmega32u4 zou moeten werken.
• DIY/zelf solderen: Arduino Pro Micro (atmega32u4) op 3v3 8MHz met cc1101 module. Helaas zijn veel cc1101 modules uit China slechte kopieën. Zie hier voor een topic met de verschillen tussen werkende en niet werkende kopie. of hier.

Ramses ESP

Inmiddels is evofw3 vervangen door Ramses ESP. In principe is dat evofw3 voor ESP32 met wifi/mqtt als extra mogelijkheden:

• Ramses_esp: Een ESP32 met kwaliteit CC1101 module, zoals SSM-D2. Sinds juni 2024 te koop bij IndaloTech
• DIY ramses kloon: vliegnerd in "Ramses II 868MHz communicatie via evofw3 en ramses_rf"
• Nog een ramses esp kloon: immrmkw in "Het grote Orcon HRC / WtW topic"

Software:

Om berichten te ontvangen, te decoderen en te verzenden kan ramses_rf gebruikt worden: https://github.com/zxdavb/ramses_rf
De maker van ramses_rf heeft ook een custom component voor de integratie in Home Assistant ontwikkeld: ramses_cc: https://github.com/zxdavb/ramses_cc

Deze combinaties worden hier al door verschillende tweakers gebruikt. De berichten staan in verschillende topics, vaak bij het apparaat dat gemonitord of bestuurd wordt. Hier kunnen we alle ervaringen/tips delen.

[ Voor 58% gewijzigd door vliegnerd op 01-10-2025 10:08 . Reden: ramses_esp apart ]

[vliegnerd]

Nanocul (oud)

EDIT: Ik gebruik inmiddels een SSM-D2 (zie bericht hieronder). Dat werkt veel beter.
Ik gebruik een nanocul v2 voor evofw3:
https://www.smart-home-ko...o-cul/nano-cul-868-extra/

Dit is een Arduino Nano (atmega328 5,5V). Niet de meest geschikte hardware. Maar ik kan helaas geen andere/betere vinden. Ik heb zelf geprobeerd om een CC1101 aan een Arduino Pro Micro (atmega 32u4) te solderen, maar dat is mijn nog niet werkend gelukt.
EDIT: die nanocul kan niet zenden. Maar de cc1101 aan een atmega32u4 pro-micro kloon hangen is nu wel gelukt en dan werkt het prima.

Omdat het mij niet zomaar lukt om de juiste software op de nanocul te flashen, hier mijn stappen plan om de nanocul eerst van de Arduino bootloader te voorzien en daarna te flashen met evofw3.

Het niet werkende deel:
Evofw3 downloaden van: https://github.com/ghoti57/evofw3/
Volg vooral de uitleg om boards.txt aan te passen uit de README.

Nanocul flashen kan volgens deze uitleg: https://github.com/ghoti57/evofw3/issues/22
Via HTerm en de DFU tool een .hex van evofw3 proberen te flashen: https://www.smarthome-age...cul-stick-testen-debugen/
(Dit ging allemaal niet soepel, een stappenplan ontbreekt hier, want het lukte mij niet)

Resultaat: Een "gebrickte" nanocul. De originele CUL bootloader was niet meer te bereiken. Ook in de Arduino IDE niet bereikbaar. Ook via de "reset 2x indrukken" truc geen bootloader meer te flashen.

Oplossing:

Een USBtinyISP programmer aangesloten op de ISP header van de nanocul. (Dit kan ook met een Arduino UNO als Arduino ISP, maar het lukte mij niet om dit voor elkaar te krijgen).

De USBtinyISP kun je voor 5 euro op Ali kopen. Ik heb een officiele van Adafruit.

In de 3x2 connector heb ik tweestuks pin headers geprikt, zodat de "female" connector een "male" connector wordt.


De connector met uitstekende pinnen kun je met de hand op de ISP header (rode vak in figuur hierboven) van de nanocul drukken. (Nokje van connector van de arduinochip af wijzend, omhoog in de figuur).
Ik moest wel met een stanleymes de heat-shrink tube voorzichtig wegsnijden. Voor de zekerheid een strookje papier onder de ISP header geschoven om kortsluiting op de printplaat eronder te voorkomen. Dat is waarschijnlijk niet nodig.

Op de USBtinyISP de jumper JP3 verbinden, zodat de arduino nano 5V krijgt van de programmer.

Nu in de Arduino IDE "Arduino Nano" als target board (dus niet het evofw3 custom board) en "USBtinyISP" als programmer kiezen en de Nano bootloader flashen.
De Nano is nu "unbricked" en ik kon de nano in een usbpoort prikken en evofw3 flashen.

Ik heb de volgende instellingen gebruikt:
(Dit kan alleen als boards.txt is ingeladen)

code:

Board: "atmega328p (SW UART)"
Processor: "atmega328p (5V, 16 MHz)"
Pinout: "Nano"
Host: "115200"
Bootloader: "Standard Bootloader"

Na flashen is de arduino bootloader verdwenen, je kunt alleen opnieuw flashen door de nanocul weer aan de ISP programmer te hangen en de bootloader opnieuw te installeren. Er is nu "gewoon" een arduino bootloader aanwezig: Je kunt evofw3 opnieuw vanuit de Arduino IDE flashen.

Na het flashen is waarschijnlijk nanoculs autotune nodig: https://github.com/ghoti57/evofw3/wiki/EVOFW3-Autotune
De frequentie van de CC1101 zender/ontvanger is afhankelijk van de preciesie van het 26.000 MHz kristal op de CC1101 module. Helaas is die meestal niet precies genoeg. Met autotune probeert de evofw3 software de frequentie iets bij te stellen zodat de ontvangst wat verbeterd wordt.

Het commando
!FT
start het autotunen.
Tussendoor kun je met !F de status opvragen, zo vaak je wil.
Na afloop kun je met !FS de nieuwe frequentie opslaan.

[ Voor 114% gewijzigd door vliegnerd op 24-04-2024 15:41 ]

[blb4]

Ik ben vandaag ook begonnen met een evofw3 project.
Ik heb een evohome systeem en een itho daalderop ventilatieysteem die beide met het Ramses_RF protocol werken. Voor mijn itho daalderop heb ik al een oplossing in de vorm van ithowifi, zie ook dit Tweaker topic. Voor evohome zijn al wel diverse integraties via de honeywell cloud API die ik ook al wel gebruik maar via evofw3 kan je zonder de API en zijn ook meer details beschikbaar. De logica van Evohome is niet helemaal geoptimaliseerd voor de combinatie met een warmtepomp dus daar moeten we dan maar eens induiken. Vandaar dus maar de start van dit projectje.
't is - zoals zo vaak - een behoorlijke zoektocht.

Ik heb een nanoCUL 868 MHz gekocht bij schlauhaus.biz. Deze kan je kopen met evofw3 firmware. Ik heb 'm gekocht met de volgende opties:



Ik heb 'm nu werkend met evoGateway op mijn raspberry pi (4). Dit was wel ff een dingetje, de raspberry heeft Python versie 3.7.3 en evoGateway werkt daar niet mee. Upgrade naar de laatste versie, 3.11.2 was geen makkelijke klus (SSL miste eerst ook waardoor de mqtt client niet geïnstalleerd kon worden enz.) maar is uiteindelijk gelukt.

Ik heb nu heel veel MQTT evohome topics, ik moet nog gaan uitzoeken wat er nu allemaal zichtbaar is en ook hoe ik commando's kan sturen.

[ Voor 22% gewijzigd door blb4 op 18-03-2023 21:48 ]

[TheMystery]

slow whoop schreef op donderdag 30 maart 2023 @ 14:16:
[...]

Wat ik eigenlijk wil is de warmtevraag zoals ik die per zone zie in het service menu op m'n Evohome thermostaat/controller uitlezen met ramses. Zo probeer ik een beter inzicht te krijgen in welke zone er nu voor zorgt dat m'n ketel gaat banden.

Ik dacht dit te kunnen uitlezen met de heat demand van de HR92 knoppen. Maar blijkbaar is dat dus niet helemaal hetzelfde. Maar volgens mij is het wel zo dat als de heat demand groter dan 0 is, er dus een warmtevraag is van die zone. Anders zo de knop helemaal dicht staan, toch?

Verder gebruik ik ook een HR92 knop voor m'n vloerverwarming. Die knop staat zo ingesteld dat ie altijd de volledige slag moet gebruiken. Zo zou die knop altijd volledig open moeten gaan bij warmtevraag voor m'n vloerverwarming. Maar de heat demand / kleppositie van die knop zie ik bijvoorbeeld ook vaak op 32 staan. Dat lijkt dus niet helemaal te kloppen.

Je zou per zone wel je heat demand moeten kunnen zien + de klep positie van de hr92:

[ccie15497]

Goedemorgen,

Graag wil een paar ervaringen en meningen delen met het monitoren en aansturen van een Orcon HRC 400.
Als domitica systeem gebruik ik Home Assistant.

Ik zie dat er een aantal topics lopen aangaande dit onderwerp.

usb fanx module, hiervan heb ik de ontwikkeling gevolgd van een afstand:
FanX RF USB Dongle
Vanaf afstand zag dit er net niet soepel genoeg uit , en het pairen van de controller lijkt een beetje op de methode die Orcon zelf gebruik voor bijvoorbeeld hun repeater module.

Omdat ik het idee had dat er met onze Orcon iets niet helemaal klopte, heb ik wat vaart erachter gezet om de Orcon te kunnen uitlezen/aansturen. En moest ik een keuze maken hoe ik de Orcon ging koppelen.

De Fanx module leek op een lager pitje te staan , en minder m'n voorkeur.

Ik heb reeds een rfxcom 433 usb ontvanger voor wat oude toellie waar ik maar niet vanaf kom , en heb even de optie voor een rfxcom 868 overwogen. Echter is de HA support vrij laag. Je kunt blijkbaar maar één rfxcom koppelen in HA. En dan moet dus eerst die 433 module met oude toellie weg. Als ik die 433 niet had gehad , was het waarschijnlijk een rfxcom 868 geworden in HA. Hardware ziet er netjes en degelijk uit.

De SSM-D2 module leek de betere oplossing. Die heb ik dan aangeschaft inclusief (geprinte) behuizing op de eerder genoemde website in UK.
Wat betreft de hardware is het ietsje minder. De module zit niet lekker in een USB poort omdat het een printplaat is , en geen nette usb stekker.
Als de print in de bijgeleverde behuizing zit , maakt ie slecht of geen contact , waardoor de oplossing minder betrouwbaar werkt.
Maar al met al , als je zorgt dat de module goed is aangesloten , en zorgt dat het radiotechnisch klopt, dus zenden/ontvangst door plaatsing juiste antenne op juiste plek.
Dan lijkt het een best aardige oplossing.

Iets wat me direct opviel, is het ontbreken van versleuteling en authenticatie, iets wat als eerder is genoemd:
slow whoop in "Ramses II 868MHz communicatie via evofw3 en ramses_rf"
Ik was in de veronderstelling dat de meeste comminucatie op 868 Mhz meestal versleuteld is.
Dat was bij 433Mhz vaak de discussie , en dat is het nog steeds.
Maar goed, blijkbaar was ik wederom iets te naief.

In feite is het dus zo dat je met de ramses_cc/rf oplossing alle communicatie kunt volgen zonder enige vorm van versteuteling of autheticatie.
Wat beteft het uitlezen en aansturen de Orcon is dit natuurlijk makkelijk.
In wezen impersonate je gewoon een bestaande remote, je hoeft dus niet een aparte remote te "maken".
Dit laatste is wel mogelijk en staat beschreven in de github wiki van Ramses_cc/rf. (oem vendor code etc)

In de configuration.yaml heb ik alle device id's vast gezet. En laat het schema automatisch discoveren.
Op dit moment heb ik nog één ding waar ik nog niet uit ben.
En dat betreft lovelace in HA



De knoppen onderin werken namelijk niet , en zijn wellicht voor een andere installaite bedoeld.
Dit zou dus betekenen dat de schema discovery niet past bij dit device.
Mocht iemand daar mee bezig zijn , dan verneem ik dat graag.

[vliegnerd]

ccie15497 schreef op maandag 19 februari 2024 @ 07:51:
De SSM-D2 module leek de betere oplossing. Die heb ik dan aangeschaft inclusief (geprinte) behuizing op de eerder genoemde website in UK.
Wat betreft de hardware is het ietsje minder. De module zit niet lekker in een USB poort omdat het een printplaat is , en geen nette usb stekker.
Als de print in de bijgeleverde behuizing zit , maakt ie slecht of geen contact , waardoor de oplossing minder betrouwbaar werkt.
Maar al met al , als je zorgt dat de module goed is aangesloten , en zorgt dat het radiotechnisch klopt, dus zenden/ontvangst door plaatsing juiste antenne op juiste plek.
Dan lijkt het een best aardige oplossing.

Ik gebruik een USB verlengkabel en een andere externe antenne: https://nl.aliexpress.com/item/32849298690.html
(cdebyte TX868-XPL-100)

Dan werkt het eigenlijk prima.

In HA heb ik de status en bediening. Inclusief automation die de boel naar stand 3 schakelt als er vocht is (douchen/koken), want mijn Orcon doet automatisch helemaal niets. (bug? fout apparaat?)
Bediening bypass klep. Filtertijd uitzelen. CO2 remotes faken. Enz Enz.



De meeste info om tot de setup van hierboven te komen vind je in onderstaande topics. Maar ik kan hier ook nog wel mijn config enzo linken. (Ik denk dat die al in die topics staan)

Dit zou dus betekenen dat de schema discovery niet past bij dit device.
Mocht iemand daar mee bezig zijn , dan verneem ik dat graag.

Er zijn een aantal forumleden met een SSM-D2 en Orcon. Hier kun je van alles vinden: Orcon HRC RF modbus in ESPHome

Maar ook in het FanX topic staat wel iets: vliegnerd in "FanX RF USB Dongle"
De auteur van rames_cc is zeer actief hier: https://community.home-as...ronics-chronotherm/151584

[ Voor 0% gewijzigd door vliegnerd op 13-04-2024 16:06 . Reden: betere link naar antenne ]

[vliegnerd]

Voor het archief:

Ik heb al lang een nanocul v1 (of v2?) in gebruik met evofw3.
Nanocul v1 is een Arduino Nano (atm328p 3.3V 8 MHz)
CC1101 868Mhz module op een dochterbordje.

https://smart-home-komponente.de/en/products/nano-cul-868

Ontvangen werkt prima.Maar deze kan helaas niet zenden.
Heeeeel soms lijkt het zenden te lukken, maar meestal loopt het ding vast.
Her en der lees je dat er nanoculs zijn die niet zenden. Nooit een oplossing kunnen vinden.

Vandaag maar eens een poging gedaan om te achterhalen of de CC1101 stuk is ofzo:
Ik heb het dochterbord met de CC1101 module eraf gesloopt en aan een Arduino Pro Micro kloon (atmega32u4 3v3 8MHz) gehangen, met een logic analyzer ertussen.

En in deze configuratie werkt het zenden prima...


(de helft van de draden is richting logic analyzer, en een reset knop enz)

Goede nieuws: Ik kan de Arduino Pro Micro op het experimenteerbordje erbij solderen en dan het ik een werkende (extra) evofw3 gateway.
Slechte nieuws: Geen gehobby met de logic analyzer nodig.

Dus ter info: De hardware van deze Nanocul werkt schijnbaar prima. (CC1011 chiversie 0x20, 26MHz crystal niet al te slecht, niet echt autotune nodig)
Maar i.c.m. nano atmega328p werkt het niet.
EDIT: Dit komt omdat de atmega328p op 3v3 werkt en daarmee op 8MHz. evofw3 werkt wel redelijk op een 328p maar dan alleen op 16MHz. Dat werkt alleen stabiel op 5v. En dan zijn er weer level shifters nodig omdat de cc1101 alleen op 3v3 werkt.

[ Voor 6% gewijzigd door vliegnerd op 02-04-2024 13:22 ]

[vliegnerd]

vliegnerd schreef op vrijdag 31 mei 2024 @ 09:28:
[...]

Ik heb al tijden een ESP32-S3 dev boardje liggen om het te testen, maar ja... tijd...

Toch maar eens geprobeerd:


ramses_esp op een ESP32 S3 DevKit C bordje.
(met een CC1101 module van een nanocul)

Eerder observaties:
- Het werkt. De USB serial port is bijna gelijk aan een evofw3 device. (SSM-D2 e.d.). Alleen de commado's !v !f e.d. werken niet meer. Er zijn wel andere commando's (reset/wifi/mqtt)
- De ESP32 zit op wifi. Geen webserver, wel MQTT.

EDIT: Ik zie helaas dat het ding wel netwerk verliest, en ik kan niet meer opnieuw verbinden. Dat is voor nu het eerste ding om op te lossen.
EDIT2: Het lijkt te bizar voor woorden, maar ESP32 dev boardjes lijken in een breadbord geen verbinding te maken met een AP. Een network/AP scan werkt wel. Ik kan bijna niet geloven dat dit de oorzaak is, maar het lijkt wel zo te zijn. (!?!)

[ Voor 17% gewijzigd door vliegnerd op 02-06-2024 18:03 ]

[vliegnerd]

Nieuwe poging om ramses_esp aan de praat te krijgen:

Het ESP32 S3 devkit C devboardje blijkt slecht wifi te ontvangen als het inprikt zit in een breadboard. (In de vrijelucht werkt het goed).

Een ESP32 S3 mini bordje (van Ali) blijkt wel redelijke wifi ontvangst te hebben in mijn breadbord. Met een paar aanpassingen draait ramses_esp daar ook op.


Met deze aanpassingen werkt het "als een trein". Een HGI-80 op de seriele port (USB) en via wifi verbonden met mijn MQTT broker. Ik zie de berichten voorbij stromen in MQTT explorer.

Serial console (een stapel ramses berichten en debug info verwijderd):

code:

idf.py monitor
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x15 (USB_UART_CHIP_RESET),boot:0x8 (SPI_FAST_FLASH_BOOT)
[...]
# ramses_esp 0.4.8
# Attempting to connect to SSID:BS17
# Connected to SSID:BS17
# MQTT: Connecting to mqtt://192.168.2.1:1883
# MQTT: Connected
082  I --- --:------ --:------ 37:245398 10E2 003 005167

Deze hoeft dus niet per se aan mijn Home Assistant doosje in de meterkast. Maar kan ook in de technische ruimte naast de Orcon FAN staan. Op die manier werkt het ook met de slechte Ali CC1101 modules die maar matig bereik/ontvanst hebben.

[vliegnerd]

Eindelijk wat tijd om weer een stapje verder te gaan.

Rames_esp kloon prototype:

Dit is een ESP32 S3 mini bordje met een zelfontworpen breakout bord voor een e07 900m10s cc1101 module.

Deze cc1101 modules zijn beter/betrouwbaarder (i.t.t. de bekende kleine bordjes zie hierboven, die vaak nep/slecht zijn). Het lijkt erop dat de ontvangst van deze module net weer een stapje beter is dan mijn vorige prototype. Nu ontvang ik nog meer devices van buren en overburen.

Ik heb een tijdje geleden een printje ontworpen en laten maken bij JLPCB. Leuke ervaring, flinke leercurve om met KiCad te leren werken, maar wel erg leuk. Kost geen drol om zo'n bordje te maken.
Dat het werkt is wel top. Het kan de volgende keer nog wel wat kleiner
De datum staat erop 240613. Heeft dus een maand in de kast gelegen.

Volgende stap is een PCB waar zo'n module en ESP32 bordje oppassen. Ik heb spijt dat ik niet een extra rijtje headers links op het bordje het gezet. Dan was het direct af. Enfin, ramses_esp heeft ook nog twee knoppen en wat LEDjes, die moeten er ook nog op. Het breakout bordje is weer voor andere project.

(De wifi doet het op dit bordje prima, ook bovenop zo'n breadbord)

[ Voor 8% gewijzigd door vliegnerd op 16-07-2024 11:47 . Reden: Link naar e07 900m10s module ]

[vliegnerd]

Ik heb de vorige dingen (zie vorige posts) gecombineerd:

Een werkende CC1101 (e07-900m10s) module met SMA antenne.
Een ESP32 S3 DevKit C bordje N16R8 met voldoende flash, zodat ramses_esp er "out of the box" op draait, met de standaard pinouts, zodat hopelijk ook OTAs werken.
In principe is dit dezelfde hardware als de "officiele" ramses ESP, maar dan DIY.


Ik moet de TX en RX LEDs nog monteren. Ik bleek de 1206 SMD leds niet te hebben. Er is ook plaats voor THT LEDs, die zal ik er dan maar opzetten.

Het bordje werkt: Ramses_esp draait out of the box.

KiCAD bestanden e.d.:
https://github.com/tomkooij/e07-900m10s-esp32s3

Ik ben nog van plan om een simpel voetje (muurbeugel) te 3D printen.

[vliegnerd]

Er was post uit China: Een paar DevKit-C bordjes. Eerder had ik een DevKit-C waarbij Wifi alleen werkt als je je hand op de antenne legt. Gelukkig bleken andere Devkit C bordjes wel gewoon met Wifi te verbinden. Blijkbaar heb ik er eentje met een slecht contact ofzo. Die gaat de onderdelen bak in voor een projectje zonder Wifi.
De boel gesoldeerd en nu maar eens testen hoe goed/slecht deze oplossing is.
(links had ik al, twee rechter zijn nieuw)

3x DevKit-C en 1x mijn eerste module op een stukje gaatjes print aan een ESP32s3 mini. Note to self: TX/RX ledjes zijn wel handig.

Het is wel grappig om de RX ledjes synchroon te zien oplichten. (Dat is die groene led op de foto).


Ik had eigenlijk alleen maar een backup nodig voor mijn (zelfbouw) evofw3 bordje. Maar dit is een beetje uit de hand gelopen.


Voorlopige testresultaten (voor zolang deze post editable is):

• Het bordje linksboven is een paar dagen ouder en draait al een paar dagen stabiel, geen problemen in HA, maar wel binnen "goed" wifi bereik, vlakbij een AP. Volgende stap: Op een hele slechte plek in huis proberen. EDIT: resultaat: Lijkt prima te gaan. Signaal schommelt tussen -66 en -65 dBm dus grens van wat acceptabel is, denk ik, en gaat zonder verstoringen. (ramses_esp bovenop de HRC WTW in technische ruimte en AP verdieping lager met beton en dikke technische ruimtedeur ertussen. Volgende poging: AP op begane grond.
• Onthou dat je niet alleen MQTT maar ook timezone en sntp moet configureren
• Als er een MQTT probleem is (disconnect) dan herstart de esp32. Dit duurt maar een paar seconden en lijkt geen problemen op te leveren, behalve een stapel logentries in HA. Het is een "work around" volgens ramses ESP github. Niet zo'n nette hack, maar lijkt weinig problemen op te leveren.
• De through hole leds met een 220 ohm weerstand zijn veel te fel. Ik heb 1000 ohm gebruikt voor de SMD ledjes. Dat is ook prima.

[ Voor 40% gewijzigd door vliegnerd op 22-08-2024 10:26 ]

[vliegnerd]

Weer wat nieuws uitgeprobeerd:

ESP32c3 supermini (minder dan 3 euro op Ali) aan mijn e07 900m10s breakout bordje met Ramses ESP erop:


Ramses ESP werkt niet helemaal "out of the box". Dit bordje heeft maar 4Mb flash, net als de ESP32s3 mini die ik al werkend had. Maar het is ook nog eens een Risc-V bordje met maar één core. De s3 heeft twee snellere xtensa LX6 cores en gebruikt er 1 voor de cc1101 module en 1 voor Wifi/MQTT. Op de c3 draait alles op één core.

Maar toch lijkt het bordje snel genoeg om Ramses_ESP inclusief Wifi en MQTT te draaien. Het werkt gewoon.

Eigenlijk ben/was ik van plan om deze te gebruiken met een ESP32c3 bordje waarvan de wifi slecht is om "bedraad" te gebruiken. Want mijn Home Assistant gebruikt een bedraad bordje met evofw3. Vind ik uiteindelijk fijner dan een enorme stortvloed van MQTT verkeer van ramses ESP.

[artifia1]

@vliegnerd was zo vriendelijk om 1 van zijn zelf ontworpen PCB's naar mij op te sturen . Nu had ik de kans om mijn "dead bug" style DIY Ramses_ESP te vervangen door een meer professionele oplossing. Het solderen van de E07 module was voor mij nog best een uitdaging, maar het is uiteindelijk best aardig gelukt:


Ik had ook nog een SMA 868mhz antenne liggen die ik over had na een recent experiment met LoRA. Nadat ik alles werkend had getest, meteen deze unit maar ingezet. Het verschil met de andere radio is goed te merken, in de afgelopen 24 uur al 10 nieuwe devices uit de buurt ontvangen.

Met deze set-up kan ik de komende jaren vooruit en kan gewoon de standaard Ramses_ESP OTA updates uitvoeren .
Bedankt @vliegnerd !

[werkmane]

Het is mij ook gelukt! En hij werkt perfect. SMD solderen was wel een uitdaging, maar is gelukt. 1k weerstanden voor de ledjes is te veel, ze zijn een beetje zwak (maar is niet erg, hoef geen disco op zonder waar ik hem hem neergezet). Moet nog wel op zoek naar een doosje.

Ik heb een een mechanische ventilator van Orcon, de MVS-15HB, met een tweetal RF15 (eentje met CO2 sensor en eentje zonder).

De CO2 sensor heb ik aan de praat in ramses_cc in HA, maar uit de ventilatie unit krijg ik geen data. Het is natuurlijk geen WTW, maar had gehoopt dat ie in iedergeval wel de ventilatiestand zou kunnen weergeven en de luchtvochtigheid. Blijkbaar mist daar nog wat support voor in ramses_cc.

Ik heb trouwens nog 4 pcb's over (zonder onderdelen), dus als iemand nog interesse heeft, stuur maar een PB.

[Forain]

Voor diegene die het interessant vinden…. Zie hieronder het leren van de evohome thermostaat.

[vliegnerd]

Uit de serie "experimenten met cc1101 bordjes":

Ik heb geprobeerd om een hele minimale HGI-80 ramses naar serial gateway te maken (ramses_esp/evofw3 kloon).

Op een PCB dat ik gemaakt heb voor een arduino pro micro om evofw3 te draaien had ik al plek gemaakt voor een ESP32 C3 supermini. Zo'n bordje heeft ook gewoon Wifi, maar slechts één RISC-V core in plaats van de 2 lx6 cores van de ESP32 S3. Omdat ramses ESP één core gebruikt voor cc1101 RF communicatie en de andere core voor Wifi/MQTT verwachtte ik eigenlijk dat deze single core oplossing niet zou werken met Wifi. Maar het werkt toch, zie verderop. Bedraad aansluiten is hier wel echt de bedoeling.

Voordeel is dat een ESP32 C3 supermini ongeveer 3 euro kost. Dus veel goedkoper en makkelijker verkrijgbaar dan een Arduino pro micro. Vandaar mijn idee om zo'n ding te bouwen als nog goedkoper alternatief voor een evofw3 bordje.

Het bordje ziet er dan zo uit:


Dit draait ramses ESP met slechts minimale aanpassingen: https://github.com/tomkooij/ramses_esp_c3/
Verrassend genoeg werkt Wifi/MQTT eigenlijk prima. Ook in mijn "drukke" RF omgeving. Er zijn 100 apparaten met ongeveer 1 bericht per seconde in mijn nieuwbouwblok.
Maar dat is eigenlijk niet mijn "bedoelde" gebruik: Dit is in ieder geval een hele goedkope zelfbouw oplossing voor een ontvanger die je bedraadt (USB C) aansluit.

PCB: https://github.com/tomkooij/promicro-cc1101

[bbn_ldp]

ccie15497 schreef op zondag 8 december 2024 @ 07:47:
[...]


Geen idee , hoe kan ik dat zien ?

Het nieuwe model is een vierkante box en het oude model uit 2017 welke ik heb heeft schuine kanten aan de in en uitlaat kanten.

[bbn_ldp]

vliegnerd schreef op zondag 15 december 2024 @ 16:40:
@bbn_ldp
In deze post kun je zien hoe je een esp32s3 aansluit op een cc1101 module om daar ramses ESP op te draaien:

Blijkbaar is mijn bordje toch weer anders dan degene waar je naar verwijst. De pins zijn anders dan op mijn bordje. Zoals op bijgesloten plaatje te zien had ik e.e.a. aangesloten volgens https://espeasy.readthedocs.io/en/latest/Plugin/P118.html maar dat gaat weer via espeasy. Kan jij mij de juiste pins aangeven vanaf de CC1101 naar de Esp32-S3?

[vliegnerd]

Niet alles werkt:

Er zijn nu esp32 c3 super mini plus modules op de markt, die een externe 2.4GHz antenne hebben, naast de chipantenne (dat rode C3 blokje):

https://www.espboards.dev/esp32/esp32-c3-super-mini-plus/

Die bordjes kosten minder dan 4 euro op Ali: https://nl.aliexpress.com/item/1005007685790119.html

Het goede nieuws: Ze werken prima. De Wifi werkt goed. (Integenstelling tot veel van die "zwarte" superminis. Die hebben vaak slechte ontvangst, dat is soms op te lossen door de chipantenne te vervangen door een stukje draadantenne, maar is behelpen)

Ze passen op mijn PCBtje. Dus eentje gekocht om eens uit te proberen:



Maar helaas. Deze supermini plus hebben een RGB led aan GPIO8. GPIO8 is hier verbonden aan cc1101 MISO. Daardoor brand de LED de hele tijd fel wit.

Ik kan die RGB led er natuurlijk weer afsolderen. Een beun-de-haas-draadje van GPIO8 naar een vrije GPIO leggen, zodat MISO op een andere GPIO komt en GPIO8 vrij blijft. Of het PCB aanpassen.
Allemaal oplossingen mogelijk, maar het werkt dus niet out-of-the-box.

[sparretje]

Dit krijg ik ik kan hem niet veranderen wat doe ik fout

[Kriseh]

Dag allemaal,

Ook ik heb een ESP32-bordje aangeschaft bij @vliegnerd. Hiermee bedien ik twee Honeywell BDR91-schakelmodules binnen mijn Evohome zoneregelingssysteem. De BDR91's zijn gekoppeld aan de pompen van vloerverwarmingsverdelers bij mij thuis. Om vastlopen te voorkomen, laat ik ze dagelijks een minuut draaien via een HA-automatiseringsscript; dit als alternatief voor traditionele pompschakelaars.

Tot vorige week had ik nog 0-ervaring met o.a. Home Assistant, Docker containers, Python, GitHub etc. Inmiddels heb ik via Marktplaats een HP T630 thin client aangeschaft, waarop ik Ubuntu Server heb geïnstalleerd en deze via SSH benader. Hierop draai ik dus nu Home Assistant in een Docker-container met daarop de Ramses_CC integratie. Voor mij een steile leercurve maar ben ontzettend dankbaar voor alle informatie die ik op Tweakers heb kunnen vinden rondom deze onderwerpen, inclusief de persoonlijke hulp van @vliegnerd.

Mijn ESP32 heb ik zelf geflasht (nadat ik deze per ongeluk had gewist), wat nog wel wat uitdagingen met zich meebracht. Hieronder wil ik graag wat kennis delen, in de hoop dat dit anderen kan helpen die zoals mij ook vrij weinig kaas hebben gegeten van microcontrollers en firmware-flashen (ook daar had ik 0-ervaring in).

De RAMSES_ESP-firmware, beschikbaar via deze link, is speciaal ontwikkeld voor het bordje dat IndaloTech verkoopt. Wil je de repository gebruiken voor een ander ESP32-bordje, dan zul je de firmware zelf moeten opbouwen volgens deze handleiding. Echter, de handleiding slaat een cruciale stap over. Na het uitvoeren van het volgende commando:

code:

idf.py set-target esp32s3

(als je de s3 hebt natuurlijk)

Moet je eerst het onderstaande commando draaien.

code:

idf.py menuconfig

Er opent zicht dan een menu waar je zaken in kunt configureren.


Binnen menuconfig moet je de pin-layout van de CC1101-communicatiemodule en de LED's aanpassen aan je specifieke bordje. Daarnaast dien je de serial flash config goed in te stellen. Doe je dit niet, dan blijft de microcontroller na het flashen in een boot-loop hangen wat bij mij dus het geval was en me veel frustratie heeft opgeleverd.

Hieronder de aanpassingen voor mijn bordje:






Zijn er nog andere zaken om rekening mee te houden @vliegnerd? Je noemde iets over de partition tables, misschien kun je dat nog aanvullen in dit topic?

Gr. Kristan

[Hippe Lip]

Alles heb ik opnieuw geïnstalleerd, maar het werkt nog steeds niet. De volgende foutmeldingen krijg ik in mijn logboek, maar kan daar helaas geen chocola van maken. Kan iemand me op weg helpen?



Een vriend heeft precies dezelfde hardware, draait op hetzelfde platform en heeft dezelfde foutmeldingen. Maar bij hem werkt het wél. Ra ra ra…

En als ik dan bij de devices kijk bij Ramses, dan is het er wel, maar alle onderdelen zijn grijs. Tik ik op zo’n onderdeel, dan zegt-ie
Het apparaat is uitgeschakeld door Configuratie-item.
Nou zoek ik me ROT wat dat ‘Configuratie-item’ is. Wie o wie kan me helpen?

[ Voor 48% gewijzigd door Hippe Lip op 05-08-2025 14:40 ]

[JoepW]

Kan iemand mij zeggen wat het juiste format is voor known devices voor mijn Evohome ramses_cc opzet. Ik kom er niet echt uit ook niet met de sterk verbeterde WiKi.

[Kriseh]

Wimpie70 schreef op zaterdag 2 augustus 2025 @ 13:44:
De 63:xxxxxx zie ik ook wel, maar wordt zover ik kan zien gebruikt door de ESP HGI bij druk verkeer, als doorgeefluik of intern gebruik. Kan dit bij jou ook zo zijn ?

De master in github is een development versie met de laatste wijzigingen voor een nieuwe release, Deze heeft o.a. al wel de clear cache fix, maar is nog in ontwikkeling. Er kunnen dus nog wijzigingen komen voordat deze gereleased wordt.

Hoe check ik dit? er is hier niet veel verkeer, mijn Evohome setje en een paar Orcon boxen (één van mijzelf, en een aantal van de buren om mijn huis heen).

Ramses mapped zelf eigenlijk al vrijwel mijn hele Evohome systeem, als ik onder de controller kijk, zie ik dit:


Als ik vervolgens op bijv. Kantoor klik, zie ik rechts onderin, bij 'Connected Devices' de TRV staan.


Dit werkt voor alle zones waar ik een TRV heb, behalve de Hobby Kamer. Als ik bij de Hobby kamer kijk, dan zie ik geen 'Connected Devices' en TRV.



Ik ben dus in de lijst van Ramses 'Devices' gaan kijken en kwam erachter dat er een 63:xxxx device was, aangeduid als HVC i.p.v. TRV, die dezelfde temperatuur doorgeeft als de zone temperatuur (afkomstig van de controller). Ook als ik de batterij er even uithaal zie ik hierover zaken in het logbook onder het 63:xxx device waardoor ik zeker weet dat deze TRV bij de hobby kamer hoort. Fysiek zien de TRV's er identiek uit.

Ik heb in mijn known list de class op TRV gezet:


Nu wordt hij ook goed weergegeven als ik naar het device ga:


Echter, is hij nu nog niet 'als 'Connected Device' onder de Zone te zien en vice-versa. Ik dacht, misschien moet ik heel simpel in het system_schema duidelijk maken dat die 63:xxxx bij zone 4 hoort, maar dan krijg ik een error 'not a valid value', zie hieronder. Als ik als proef, de waarde hieronder van 63 naar 04 aanpas, verder niks anders wijzig, dan accepteert hij het gek genoeg wel en kan ik de configuratie opslaan. Het lijkt wel of hij een validatie doet en een 63:xxx hier niet accepteert.



Dus heel kort mijn vraag: Hoe krijg ik nu de link tussen de Hobby Kamer en de TRV? Ik dacht via System Schema maar die slikt een 63:xxx als sensor niet om de één of andere reden.

PS. ik zit op de laatste versie (0.51.5)

[golfdiesel]

In mijn setup voor het Honeywell Evohome systeem heb ik een tweetal losse temperatuursensoren gekoppeld die als temperatuur sensor werken voor de betreffende ruimte.
Deze sensoren worden wel gezien maar er is geen meetwaarde via Ramses. Heeft iemand deze sensor zichtbaar in HA?

[golfdiesel]

JoepW schreef op zaterdag 20 september 2025 @ 20:34:
[...]

Is deze zone soms de laatste toegevoegde zone en/of de laatste zone in config file die in de .storage directory staat?
Ik heb dit namelijk ook en die zone voldoet aan deze criteria.

Dat moet ik nog even bekijken maar ik zie hetzelfde bij twee zones waar ik dit type temperatuur sensor gebruik. In een 3e zone gebruik ik een Honeywell round als sensor (achteraf gezien beter omdat die goedkoper is dan de losse sensor).
Het is de HCF82 ruimte sensor.

[Kriseh]

Kriseh schreef op zondag 14 september 2025 @ 09:06:
[...]


Heb de zone meermaals verwijderd uit de Evohome controller, de toewijzing uit de HR92 gewist, HR92 vervolgens naar fabrieksinstellingen en alles opnieuw. Helaas werkt het nog steeds niet. Ik ga vandaag op vakantie dus ga er mee verder zodra ik terugkom. Ik heb ook nog een reserve HR92 liggen waar ik ook eens mee kan troubleshooten. Ik kom hier op een later moment op terug!

Zoals beloofd met een andere HR92 geprobeerd en dat werkte meteen! Deze heeft ook netjes een 04:x serienummer i.p.v. 63:x.

Even samenvattend kreeg ik het met de HR92 met 63:X serienummer niet voor elkaar om de TRV onder de zone te zien, zelfs na meermaals de zone in het evohome systeem verwijderd en opnieuw aangemaakt te hebben. Nu met die spare die ik had liggen dus wel.

[ Voor 34% gewijzigd door Kriseh op 03-10-2025 15:53 ]

[Gerritjuh]

vliegnerd schreef op zondag 5 oktober 2025 @ 19:19:
[...]

Ook zonder antenne werkt het ontvangen meestal prima. Die e07 900m10s modules zijn erg gevoelig.
Zonder antenne zenden lijkt mij wel riskant, maar een 2,4ghz antenne is vaak even goed/slecht als een 900Mhz.

Ik heb een bordje met een e07 433m10s en die doet het ook prima met 868Mhz…

Tof dat je een bordje gemaakt hebt. Stuur foto’s

Een van de uitdagingen was het correct verwerken van de MQTT berichten. Beetje naief geweest en de SNTP server nog niet ingesteld, dan werkt het niet lekker. Je ziet wel de verschillende apparaten maar die communiceren verder niet. Vandaag kwam ik daarachter en na het instellen van de SNTP ging bijna alles automatisch. Ik ben nu aan het bestuderen wat alles nu precies betekend (3-letter omschrijvingen en de ID's), maar daar helpt ChatGPT weer heel goed.

De antenne laat ik even voor wat het is, waarschijnlijk een 2,4GHz antenne, maar de gehele huisinstallatie lijkt compleet te worden weergegeven.

Wel een tip voor de beginner (net zoals ik). Als je in de seriele console iets wil aanpassen moet je gewoon blind typen. Tijdens het intoetsen blijven de log regels doorlopen. In het begin dacht ik dat ik iets niet goed had gedaan, maar na het geven van het commando en op enter drukken krijg je wel de bevestiging te zien. Voor de console kan je in Windows gewoon Putty gebruiken en dan de juiste com-poort instellen.

En dan nu de gevraagde foto's:

[ebroerse]

Net uitgekomen: Ramses RF 0.51.9

Nieuwe optie gemaakt door @Wimpie70 : _Fan parameters_ via 2411 messages. De instellingen verschijnen op een Configuratie paneel onder de Ramses RF integratie als je fan ze ondersteunt. Je kunt instellingen aanpassen met 3 nieuwe Fan actions.


Noot: ramses_cc custom integratie versie 0.51.8 en later vereisen HA 2025.10.0 of nieuwer.
Check de release notes voor details.