Ramses II 868MHz communicatie via evofw3 en ramses_rf

[rfcdejong]

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


Ja klopt, als ik de code op github bekijk, dan kan die hetzelfde doen als een SSM-D2 (RF naar USB bridge) maar ook tegelijkertijd RF naar MQTT.

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

Thanks.
Voor nu maar een nanoCell besteld, want tja.. beter dan niets. En helaas zag ik te laat dat jij een RF te koop heb, ik had een paar dagen geleden die nieuw aangeschaft.

[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.

[Vaevictis_]

vliegnerd schreef op zaterdag 8 juni 2024 @ 16:36:
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.
[Afbeelding]

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.

Wat je nog kunt doen is een draad antenne (dupont kabeltje) solderen op de esp. Heb dat ook vaak gedaan en werkt goed.

[vliegnerd]

Vaevictis_ schreef op zaterdag 8 juni 2024 @ 16:51:
[...]


Wat je nog kunt doen is een draad antenne (dupont kabeltje) solderen op de esp. Heb dat ook vaak gedaan en werkt goed.

Ik heb dat op Youtube gezien inderdaad. (Zowel een draadje aan het eind van de PCB antenne als een soort verlengstuk en echt als vervanging, waarbij de printsporen worden blootgelegd, door gekrast en vervangen door een draadje of volledige antenne).

Maar ik hoop voorlopig dat de standaard PCB antenne het "gewoon" doet. Ik moet het DevKitC bordje nog testen op een stukje experimenteerprint ipv breadboard, om te zien of daarmee een wat meer permanente versie gemaakt kan worden. Met de/een CC1101 module eraan vast gesoldeerd. RX ledje enzo. Hopelijk werkt de wifi dan nog.
Anders wellicht toch een draadje proberen te solderen. Dank!

[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 KiCad bestanden en gerbers van het CC1101 bordje op Github gezet: https://github.com/tomkooij/e07-900m10s-breakout

[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.

[werkmane]

Mooi werk! Wat kosten de verschillende onderdelen ongeveer en waar kan je die cc1101 kopen?

[vliegnerd]

werkmane schreef op woensdag 14 augustus 2024 @ 22:15:
Mooi werk! Wat kosten de verschillende onderdelen ongeveer en waar kan je die cc1101 kopen?

Als je alles in bulk koopt ben je met 10 euro klaar Maar helaas is dat niet zo makkelijk. Een realistische prijs is >20 euro.

Zoals je hierboven kunt zien had ik eerst een DevKit C bordje van Aliexpress dat slecht/geen Wifi heeft. Aliexpress is vaak "goedkoop is duurkoop". Je moet ofwel goed weten wat/waar je koopt, of geluk hebben.
Met cc1101 modules is dat, zoals bekend, helemaal een probleem. Al die vierkante groene bordjes lijken slechte kopieën die meestal niet of slecht werken.

De e07900m10s cc1101 module wordt gemaakt door Ebyte. Die heb ik op Aliexpress gekocht by "cdebyte", volgens mij is dat de officiële Aliexpress winkel van Ebyte. Deze link.

Die module kost 5 euro (2,50 + 2,50 verzendkosten). Ik zie ze nu ook goedkoper, maar van een andere aanbieder. Dan is het weer de vraag of het het origineel is, of een kopie. En of die kopie dan werkt enz.

Op GitHub (https://github.com/tomkooij/e07-900m10s-esp32s3) staat de volledige lijst met onderdelen.

[ Voor 6% gewijzigd door vliegnerd op 15-08-2024 09:12 . Reden: Github link ]

[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 !

[vliegnerd]

artifia1 schreef op zondag 15 september 2024 @ 20:28:
Met deze set-up kan ik de komende jaren vooruit en kan gewoon de standaard Ramses_ESP OTA updates uitvoeren .
Bedankt @vliegnerd !

Geweldig dat het werkt en dat de ontvangst goed is!

Wat betreft de OTA, heb je zelf gecompileerd met in achtneming van deze issue: https://github.com/espressif/esp-idf/issues/13497
Of heb je ramses_esp.bin van github geflashed?

(In het geval van het laatste, hoe doe je dat? )

Ikzelf heb een ESP-IDF met commit 9525da0 reverted en ik compileer dan versie 0.4.8 en voer een ota update uit naar 0.4.9.
Maar dat is één van de dingen die nog op het "nog eens goed testen" lijstje staat.
EDIT: Nog eens een keer getest en dit werkt prima.

code:

# ramses_esp 0.4.8
[...]
ota start
# ota start
# OTA: Running firmware version: 0.4.8
# OTA: downloading firmware version 0.4.9
[...]
# OTA: Upgrade complete. Rebooting ...
# MQTT: Disonnected
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
[...]
# ramses_esp 0.4.9

[ Voor 21% gewijzigd door vliegnerd op 17-09-2024 16:39 . Reden: OTA getest ]

[artifia1]

Ik had eerst de bin geflashed met "flash download tool" . Maar had helaas geen ervaring met de dubbele USB-C poort, en kreeg geen ramses berichten te zien. Toen maar zelf gecompileerd, ook geen berichten te zien en vervolgens andere usb poort geprobeerd. Je hebt het zelf getest, ik zou verwachten dat het ook gewoon werkt.

[vliegnerd]

artifia1 schreef op woensdag 18 september 2024 @ 19:27:
Ik had eerst de bin geflashed met "flash download tool" . Maar had helaas geen ervaring met de dubbele USB-C poort, en kreeg geen ramses berichten te zien. Toen maar zelf gecompileerd, ook geen berichten te zien en vervolgens andere usb poort geprobeerd. Je hebt het zelf getest, ik zou verwachten dat het ook gewoon werkt.

Als je zelf compileert dan werkt de OTA in principe niet, vanwege een bug in de ESP IDF framework.
Als je de instructies uit de gelinkte issue uitvoert (git revert ...) en dan opnieuw compileert, dan werkt de OTA wel.

[artifia1]

Ik heb idf5.2 gebruikt, daar zou OTA in gefixed moeten zijn? ik heb alleen nog geen nieuwe versie om te testen....

[vliegnerd]

artifia1 schreef op donderdag 19 september 2024 @ 10:27:
Ik heb idf5.2 gebruikt, daar zou OTA in gefixed moeten zijn? ik heb alleen nog geen nieuwe versie om te testen....

In 5.2.1 is het NIET gefixed. Ramses_ESP compileert niet zomaar in 5.2.2 (meest recente versie) want gepinned aan 5.2.1.

Ik compileer dus 0.4.8 en voer daarna een OTA update uit:

code:

#In de map van ESP-IDF
git revert 9525da0
#in de map van ramses_esp
git checkout v0.4.8
git reset --hard # weet niet zeker of dit nodig is
idf.py fullclean # en dan alsnog de build map verwijderen 
idf.py set-target esp32s3
idf.py build flash monitor
# dan in de serial console van ramses_esp
ota start

[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.

[werkmane]

Ik heb trouwens IDF 5.2.2 gebruikt (heb ramses_esp IDF versie gepinned op die versie en daarna gecompileerd). Heb overigens OTA nog niet getest.

[vliegnerd]

werkmane schreef op vrijdag 1 november 2024 @ 20:23:
[Afbeelding]

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.

Heel gaaf dat je hem ook gemaakt hebt!
Ik hoop dat je nog wat mensen blij kunt maken met de andere PCBs!

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 denk dat de MVS-15 geen 31DA berichten stuurt. Dat is wat ik heb begrepen uit andere topics. In die 31DA berichten zit de info zoals fan snelheid, luchtvochtigheid e.d. Die info is er (denk ik) helemaal niet.
Het is dus hoogstwaarschijnlijk geen ramses_cc ding.

ramses_cc maakt een bestand "config/packet.log" aan in Home Assistant. Daarin staat per regel elk ontvangen ramses II bericht.

Als je alle berichten bekijkt die jouw MVS-15 verzendt en ontvangt, dan kom je er snel genoeg achter.
Je zoekt 31D9 of 31DA berichten.

Als je echt per bericht wil uitvogelen wat het betekent, dan kun je dat wel in de broncode van ramses_rf (de onderliggen RF laag van ramses_cc, die tegenwoordig weer ramses RF heet om het eenvoudig te houden...)
31D9 en 31DA vind je bijvoorbeeld hier: https://github.com/zxdavb...amses_tx/parsers.py#L2107

[Forain]

vliegnerd schreef op vrijdag 1 november 2024 @ 21:55:
[...]

Heel gaaf dat je hem ook gemaakt hebt!
Ik hoop dat je nog wat mensen blij kunt maken met de andere PCBs!


[...]


Ik denk dat de MVS-15 geen 31DA berichten stuurt. Dat is wat ik heb begrepen uit andere topics. In die 31DA berichten zit de info zoals fan snelheid, luchtvochtigheid e.d. Die info is er (denk ik) helemaal niet.
Het is dus hoogstwaarschijnlijk geen ramses_cc ding.

ramses_cc maakt een bestand "config/packet.log" aan in Home Assistant. Daarin staat per regel elk ontvangen ramses II bericht.

Als je alle berichten bekijkt die jouw MVS-15 verzendt en ontvangt, dan kom je er snel genoeg achter.
Je zoekt 31D9 of 31DA berichten.

Als je echt per bericht wil uitvogelen wat het betekent, dan kun je dat wel in de broncode van ramses_rf (de onderliggen RF laag van ramses_cc, die tegenwoordig weer ramses RF heet om het eenvoudig te houden...)
31D9 en 31DA vind je bijvoorbeeld hier: https://github.com/zxdavb...amses_tx/parsers.py#L2107

Ik heb zelf ook een MVS-15, en ik heb hetzelfde probleem. Wat ik heb uitgevonden is dat ramses_rf het gewoon snapt.

packet.log

code:

2024-11-03T19:13:56.141016 078  I --- 29:211060 --:------ 29:211060 31D9 003 000004

home-assistant.log

code:

2024-11-03 19:13:56.141 INFO (MainThread) [ramses_rf.dispatcher] ||  29:211060 |            |  I | fan_state        |  00  || {'hvac_id': '00', 'exhaust_fan_speed': 0.02, 'fan_mode': '04', 'passive': False, 'damper_only': False, 'filter_dirty': False, 'frost_cycle': False, 'has_fault': False, '_flags': [0, 0, 0, 0, 0, 0, 0, 0]}

Als je in https://github.com/zxdavb.../ramses_rf/device/hvac.py bij regel 364

zie je dat code 31D9 niet wordt aangestuurd, terwijl dat wel gebeurde.

code:

    @property
    def exhaust_fan_speed(self) -> float | None:  # was from: (Code._31D9, Code._31DA)
        return self._msg_value(Code._31DA, key=SZ_EXHAUST_FAN_SPEED)

Ik heb zelf in mij home assistant dit aangepast (Code._31DA => 31D9) en dat werkte. Dus weet ik waar ik naar moet zoeken, alleen moet ik de boel forken, en eigenlijk een separate device voor maken etc, daar heb ik eerst geen tijd voor....

En als je de bron zoek in je HACS vind je dat niet in je custom_components, maar bij de site-packages (a.k.a de depencies)

Eerst een ander probleem oplossen... Een van de HR92 kraantjes raakt het signaal door 2x 250mm beton regelmatig kwijt.

[vliegnerd]

Forain schreef op zondag 3 november 2024 @ 19:20:
[...]


Ik heb zelf ook een MVS-15, en ik heb hetzelfde probleem. Wat ik heb uitgevonden is dat ramses_rf het gewoon snapt.

packet.log

code:

2024-11-03T19:13:56.141016 078  I --- 29:211060 --:------ 29:211060 31D9 003 000004

home-assistant.log

code:

2024-11-03 19:13:56.141 INFO (MainThread) [ramses_rf.dispatcher] ||  29:211060 |            |  I | fan_state        |  00  || {'hvac_id': '00', 'exhaust_fan_speed': 0.02, 'fan_mode': '04', 'passive': False, 'damper_only': False, 'filter_dirty': False, 'frost_cycle': False, 'has_fault': False, '_flags': [0, 0, 0, 0, 0, 0, 0, 0]}

Als je in https://github.com/zxdavb.../ramses_rf/device/hvac.py bij regel 364

zie je dat code 31D9 niet wordt aangestuurd, terwijl dat wel gebeurde.

code:

    @property
    def exhaust_fan_speed(self) -> float | None:  # was from: (Code._31D9, Code._31DA)
        return self._msg_value(Code._31DA, key=SZ_EXHAUST_FAN_SPEED)

Ik heb zelf in mij home assistant dit aangepast (Code._31DA => 31D9) en dat werkte. Dus weet ik waar ik naar moet zoeken, alleen moet ik de boel forken, en eigenlijk een separate device voor maken etc, daar heb ik eerst geen tijd voor....

Eerst een ander probleem oplossen... Een van de HR92 kraantjes raakt het signaal door 2x 250mm beton regelmatig kwijt.

Aha! Goed gevonden.

Een issue maken op Github met deze beschrijving en/of een post in het "officiele" ramses_cc forum zal er wel voor zorgen dat dit opgelost wordt door David Bonnes.

Hij is vaak heel snel met implementeren en nieuwe release uitbrengen. Mits je een goed ruim packet.log stuurt en een duidelijke beschrijving van je apparatuur.

[REDN4S]

Goedemorgen,

Ik heb thuis op zolder de CV hangen met honeywell kastjes ernaast voor de aansturing. achter het schot ( 1 meter afstand) zit de ventilatie (Orcon Compact 10RHB). Wij hebben veel last gehad van communicatieproblemen en vorige maand is de ventilatie kapot gegaan dus opgestuurd naar de leverancier. sindsdien hebben wij geen communicatieproblemen meer. Na wat lezen op internet kwam ik erachter dat zowel Honeywell als Orcon gebruik maken van het Ramses II protocol.

Mogelijk is dit niet helemaal het geschikte topic hierover maar gezien jullie kennis hierover mijn vraag: Is het mogelijk dat Orcon de communicatie verstoort met Honeywell? Ze zitten allebei op hetzelfde protocol maar ik weet niet of ze ook allebei de berichten van elkaar ontvangen/verwerken/storen?

[vliegnerd]

REDN4S schreef op woensdag 6 november 2024 @ 10:57:
Goedemorgen,

Ik heb thuis op zolder de CV hangen met honeywell kastjes ernaast voor de aansturing. achter het schot ( 1 meter afstand) zit de ventilatie (Orcon Compact 10RHB). Wij hebben veel last gehad van communicatieproblemen en vorige maand is de ventilatie kapot gegaan dus opgestuurd naar de leverancier. sindsdien hebben wij geen communicatieproblemen meer. Na wat lezen op internet kwam ik erachter dat zowel Honeywell als Orcon gebruik maken van het Ramses II protocol.

Mogelijk is dit niet helemaal het geschikte topic hierover maar gezien jullie kennis hierover mijn vraag: Is het mogelijk dat Orcon de communicatie verstoort met Honeywell? Ze zitten allebei op hetzelfde protocol maar ik weet niet of ze ook allebei de berichten van elkaar ontvangen/verwerken/storen?

Nee, die kans is heel erg klein. Ze zenden op dezelfde frequentie, maar ze zenden heel korte berichten en herhalen die berichten vaak. Dus een keertje storing zou kunnen, maar als je slecht bereik / ontvangst hebt dan is storing niet de oorzaak.

In een modern nieuwbouwhuis ontvang je soms 100+ aparaten, vanjezelf en de buren. Dat gaat allemaal prima. (Ik ontvang er zelf 90+)

[Forain]

REDN4S schreef op woensdag 6 november 2024 @ 10:57:
Goedemorgen,

Ik heb thuis op zolder de CV hangen met honeywell kastjes ernaast voor de aansturing. achter het schot ( 1 meter afstand) zit de ventilatie (Orcon Compact 10RHB). Wij hebben veel last gehad van communicatieproblemen en vorige maand is de ventilatie kapot gegaan dus opgestuurd naar de leverancier. sindsdien hebben wij geen communicatieproblemen meer. Na wat lezen op internet kwam ik erachter dat zowel Honeywell als Orcon gebruik maken van het Ramses II protocol.

Mogelijk is dit niet helemaal het geschikte topic hierover maar gezien jullie kennis hierover mijn vraag: Is het mogelijk dat Orcon de communicatie verstoort met Honeywell? Ze zitten allebei op hetzelfde protocol maar ik weet niet of ze ook allebei de berichten van elkaar ontvangen/verwerken/storen?

Ik heb nu sinds kort ramses_esp draaien op zolder (i.v.m. het niet 100% doorkrijgen van een van de signalen), en ik heb nu 40 Orcon boxen gevonden (nieuwbouw plan met identieke huizen). En eigenlijk is er geen verstoring (anders dan signaal moeilijker door beton kom).

Het uitgangspunt van ramses is dat je juist niet continu uitzend. Een HR92 zend ongeveer 1x per uur of wanneer de temperatuur wijzigt (ivm klep posities).

[werkmane]

[..]

Als je in https://github.com/zxdavb.../ramses_rf/device/hvac.py bij regel 364

zie je dat code 31D9 niet wordt aangestuurd, terwijl dat wel gebeurde.

code:

    @property
    def exhaust_fan_speed(self) -> float | None:  # was from: (Code._31D9, Code._31DA)
        return self._msg_value(Code._31DA, key=SZ_EXHAUST_FAN_SPEED)

Ik heb zelf in mij home assistant dit aangepast (Code._31DA => 31D9) en dat werkte. Dus weet ik waar ik naar moet zoeken, alleen moet ik de boel forken, en eigenlijk een separate device voor maken etc, daar heb ik eerst geen tijd voor....

En als je de bron zoek in je HACS vind je dat niet in je custom_components, maar bij de site-packages (a.k.a de depencies)

Dank voor de tip, eens kijken of ik een MV schema kan maken ipv een FAN schema welke voor HRUs is, met alleen de status van de MV. Maar eerst tijd vinden

[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 maandag 19 februari 2024 @ 07:51:
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.

Betreft dit de oude HRC400 of het nieuwe model?

[ccie15497]

bbn_ldp schreef op zaterdag 7 december 2024 @ 18:03:
[...]

Betreft dit de oude HRC400 of het nieuwe model?

Geen idee , hoe kan ik dat zien ?

[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.

[ccie15497]

bbn_ldp schreef op maandag 9 december 2024 @ 21:12:
[...]

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.
[Afbeelding]

Ah duidelijk , dan gaat het in mijn geval om het nieuwe model , een vierkante blokkendoos uit 2021

[bbn_ldp]

Ik heb een FanX stick van Willie Wortel draaien in Home Assistant, maar hiermee kan ik tot nu toe alleen de ventilatiestanden uitlezen en bedienen. Tot nu toe is het mij niet gelukt om meer gegevens uit de Orcon 15 HRC400 (Model 2017) te krijgen. Ik heb wel foto's van de printplaten waarop een utp poort is te zien, maar of daar iets mee kan weet ik niet.

Nu heb ik nog wat Lilygo T7 S3 (esp32-S3) boardjes en vraag mij af of er ergens een schema is om een NRF905 of een CC1101 hierop aan te sluiten en welke firmware ik dan het beste kan gebruiken. Is er ergens een stap voor stap handleiding om e.e.a. in Home Assistant aan de praat te krijgen, zodat ik de rest van de signalen uit de Orcon kan opvangen? Ramses RF heb ik wel al geïnstalleerd in Home Assistant.

[vliegnerd]

@bbn_ldp
In deze post kun je zien hoe je een esp32s3 aansluit op een cc1101 module om daar ramses ESP op te draaien:
vliegnerd in "Ramses II 868MHz communicatie via evofw3 en ramses_rf"
Met schema's gerbers enz.

Een paar posts hierboven staat een versie voor een esp32c3 incl schema/pcb/gerbers: vliegnerd in "Ramses II 868MHz communicatie via evofw3 en ramses_rf"
Als je de github link in die post bekijkt, dan zie je de aanpassing voor esp32c3 en zou je een heel eind moeten komen met aansluiten/flashen enz enz.

Als je zo'n bordje werkend hebt dan kun je in het Orcon WTW topic vinden hoe je dat dan weer in ramses_cc/rf zet: Het grote Orcon HRC / WtW topic

[ Voor 13% gewijzigd door vliegnerd op 15-12-2024 16:46 ]

[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:
vliegnerd in "Ramses II 868MHz communicatie via evofw3 en ramses_rf"
Met schema's gerbers enz.

Een paar posts hierboven staat een versie voor een esp32c3 incl schema/pcb/gerbers: vliegnerd in "Ramses II 868MHz communicatie via evofw3 en ramses_rf"
Als je de github link in die post bekijkt, dan zie je de aanpassing voor esp32c3 en zou je een heel eind moeten komen met aansluiten/flashen enz enz.

Als je zo'n bordje werkend hebt dan kun je in het Orcon WTW topic vinden hoe je dat dan weer in ramses_cc/rf zet: Het grote Orcon HRC / WtW topic

Bedankt ik ga kijken hoever ik er mee kom

[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]

bbn_ldp schreef op zondag 15 december 2024 @ 17:48:
[...]

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?
[Afbeelding]

De standaard pinouts voor ramses ESP zijn:

GPIO35: MOSI
GPIO36: SCK
GPIO37: MISO
GPIO38: CSN
GPIO39: GDO0
GPIO40: GDO2

Maar zover ik kan zie heeft het Lilygo T7 die pinnen van de esp32s3 niet standaard aan een pin van de module hangen (https://github.com/Xinyua...tab=readme-ov-file#pinout)

Maar je kunt ramses ESP opnieuw compileren met de pinouts die horen bij jouw bordje. In mijn ESP32c3 versie doe ik dat ook, want die heeft die GPIOs ook niet.

Als je ramses ESP compileert kun je in menuconfig de CC1101 pins kiezen:
https://github.com/Indalo...sp/wiki/Building-firmware

code:

idf.py set-target esp32s3
idf.py menuconfig    # CC1101 menu de juiste pins invullen
idf.py build flash monitor

Ik zou gewoon de pins aanhouden je je nu hebt gekozen voor ESPEasy.
MOSI zit aan GPIO13, dus je vult "13" in bij MOSI, "14" bij SCK enzovoorts.
Je moet dan wel GDO0 ook aansluiten want ramses ESP gebruikt zowel GDO2 als GDO0.

[ Voor 5% gewijzigd door vliegnerd op 15-12-2024 19:08 ]

[Verwijderd]

Hm ik loop tegen een probeempje aan met het compilen, ik kan de standaard firmware van ramses esp schijnbaar niet flashes naar m'n esp32 s3 N16 model. Zelf compilen wil ook niet, dacht eerst dat het aan m'n mac lag, maar op Debian hetzelfde:

code:

NOTICE: [1/1] idf (5.2.1)
-- Project sdkconfig file /home/neo/ramses_esp/sdkconfig
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/home/neo/.espressif/python_env/idf5.2_py3.11_env/lib/python3.11/site-packages/kconfgen/__main__.py", line 16, in <module>
    main()
  File "/home/neo/.espressif/python_env/idf5.2_py3.11_env/lib/python3.11/site-packages/kconfgen/core.py", line 402, in main
    output_function(deprecated_options, config, temp_file)
  File "/home/neo/.espressif/python_env/idf5.2_py3.11_env/lib/python3.11/site-packages/kconfgen/core.py", line 735, in write_json_menus
    write_node(n)
  File "/home/neo/.espressif/python_env/idf5.2_py3.11_env/lib/python3.11/site-packages/kconfgen/core.py", line 697, in write_node
    int(max_range.str_value, base),
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: invalid literal for int() with base 10: ''
Loading defaults file /home/neo/ramses_esp/sdkconfig.defaults...
/home/neo/ramses_esp/sdkconfig.defaults:20 CONFIG_TCPIP_TASK_AFFINITY_CPU0 was replaced with CONFIG_LWIP_TCPIP_TASK_AFFINITY_CPU0
/home/neo/ramses_esp/sdkconfig.defaults:21 CONFIG_TCPIP_TASK_AFFINITY was replaced with CONFIG_LWIP_TCPIP_TASK_AFFINITY
warning: CC_MOSI_GPIO has no value set in the configuration. This can be caused e.g. by missing default value for the current chip version.
warning: CC_SCK_GPIO has no value set in the configuration. This can be caused e.g. by missing default value for the current chip version.
warning: CC_MISO_GPIO has no value set in the configuration. This can be caused e.g. by missing default value for the current chip version.
warning: CC_CSN_GPIO has no value set in the configuration. This can be caused e.g. by missing default value for the current chip version.
warning: CC_GDO0_GPIO has no value set in the configuration. This can be caused e.g. by missing default value for the current chip version.
warning: CC_GDO2_GPIO has no value set in the configuration. This can be caused e.g. by missing default value for the current chip version.
CMake Error at /home/neo/esp-idf/tools/cmake/kconfig.cmake:209 (message):
  Failed to run kconfgen
  (/home/neo/.espressif/python_env/idf5.2_py3.11_env/bin/python;-m;kconfgen;--list-separator=semicolon;--kconfig;/home/neo/esp-idf/Kconfig;--sdkconfig-rename;/home/neo/esp-idf/sdkconfig.rename;--config;/home/neo/ramses_esp/sdkconfig;--defaults;/home/neo/ramses_esp/sdkconfig.defaults;--env-file;/home/neo/ramses_esp/build/config.env).
  Error 1
Call Stack (most recent call first):
  /home/neo/esp-idf/tools/cmake/build.cmake:615 (__kconfig_generate_config)
  /home/neo/esp-idf/tools/cmake/project.cmake:605 (idf_build_process)
  CMakeLists.txt:6 (project)


-- Configuring incomplete, errors occurred!
See also "/home/neo/ramses_esp/build/CMakeFiles/CMakeOutput.log".
cmake failed with exit code 1

Iemand enig idee toevallig? Dit is met een verse clone van de ramses repo en de 5.2.1 idf. Ik verdenk hem ervan de Kconfig files van de components niet te zien maar heb geen idee hoe het te fixen.

[vliegnerd]

Verwijderd schreef op maandag 30 december 2024 @ 15:34:
Hm ik loop tegen een probeempje aan met het compilen, ik kan de standaard firmware van ramses esp schijnbaar niet flashes naar m'n esp32 s3 N16 model. Zelf compilen wil ook niet, dacht eerst dat het aan m'n mac lag, maar op Debian hetzelfde:

code:

NOTICE: [1/1] idf (5.2.1)
-- Project sdkconfig file /home/neo/ramses_esp/sdkconfig
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/home/neo/.espressif/python_env/idf5.2_py3.11_env/lib/python3.11/site-packages/kconfgen/__main__.py", line 16, in <module>
    main()
  File "/home/neo/.espressif/python_env/idf5.2_py3.11_env/lib/python3.11/site-packages/kconfgen/core.py", line 402, in main
    output_function(deprecated_options, config, temp_file)
  File "/home/neo/.espressif/python_env/idf5.2_py3.11_env/lib/python3.11/site-packages/kconfgen/core.py", line 735, in write_json_menus
    write_node(n)
  File "/home/neo/.espressif/python_env/idf5.2_py3.11_env/lib/python3.11/site-packages/kconfgen/core.py", line 697, in write_node
    int(max_range.str_value, base),
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: invalid literal for int() with base 10: ''
Loading defaults file /home/neo/ramses_esp/sdkconfig.defaults...
/home/neo/ramses_esp/sdkconfig.defaults:20 CONFIG_TCPIP_TASK_AFFINITY_CPU0 was replaced with CONFIG_LWIP_TCPIP_TASK_AFFINITY_CPU0
/home/neo/ramses_esp/sdkconfig.defaults:21 CONFIG_TCPIP_TASK_AFFINITY was replaced with CONFIG_LWIP_TCPIP_TASK_AFFINITY
warning: CC_MOSI_GPIO has no value set in the configuration. This can be caused e.g. by missing default value for the current chip version.
warning: CC_SCK_GPIO has no value set in the configuration. This can be caused e.g. by missing default value for the current chip version.
warning: CC_MISO_GPIO has no value set in the configuration. This can be caused e.g. by missing default value for the current chip version.
warning: CC_CSN_GPIO has no value set in the configuration. This can be caused e.g. by missing default value for the current chip version.
warning: CC_GDO0_GPIO has no value set in the configuration. This can be caused e.g. by missing default value for the current chip version.
warning: CC_GDO2_GPIO has no value set in the configuration. This can be caused e.g. by missing default value for the current chip version.
CMake Error at /home/neo/esp-idf/tools/cmake/kconfig.cmake:209 (message):
  Failed to run kconfgen
  (/home/neo/.espressif/python_env/idf5.2_py3.11_env/bin/python;-m;kconfgen;--list-separator=semicolon;--kconfig;/home/neo/esp-idf/Kconfig;--sdkconfig-rename;/home/neo/esp-idf/sdkconfig.rename;--config;/home/neo/ramses_esp/sdkconfig;--defaults;/home/neo/ramses_esp/sdkconfig.defaults;--env-file;/home/neo/ramses_esp/build/config.env).
  Error 1
Call Stack (most recent call first):
  /home/neo/esp-idf/tools/cmake/build.cmake:615 (__kconfig_generate_config)
  /home/neo/esp-idf/tools/cmake/project.cmake:605 (idf_build_process)
  CMakeLists.txt:6 (project)


-- Configuring incomplete, errors occurred!
See also "/home/neo/ramses_esp/build/CMakeFiles/CMakeOutput.log".
cmake failed with exit code 1

Iemand enig idee toevallig? Dit is met een verse clone van de ramses repo en de 5.2.1 idf. Ik verdenk hem ervan de Kconfig files van de components niet te zien maar heb geen idee hoe het te fixen.

Heb je de instructies uit de vorige post letterlijk gedaan?

code:

idf.py set-target esp32s3
idf.py menuconfig    # CC1101 menu de juiste pins invullen
idf.py build flash monitor

[Verwijderd]

Thanks, afraid so:

code:

neo@neo-server:~/ramses_esp$ idf.py set-target esp32s3
Adding "set-target"'s dependency "fullclean" to list of commands with default set of options.
Executing action: fullclean
Directory '/home/neo/ramses_esp/build' doesn't seem to be a CMake build directory. Refusing to automatically delete files in this directory. Delete the directory manually to 'clean' it.
neo@neo-server:~/ramses_esp$ rm -Rf build/
neo@neo-server:~/ramses_esp$ idf.py menuconfig

Zelfde error op zowel macos als debian. Heb even geen Windows voorhanden.

[vliegnerd]

Verwijderd schreef op maandag 30 december 2024 @ 15:45:
Thanks, afraid so:

code:

neo@neo-server:~/ramses_esp$ idf.py set-target esp32s3
Adding "set-target"'s dependency "fullclean" to list of commands with default set of options.
Executing action: fullclean
Directory '/home/neo/ramses_esp/build' doesn't seem to be a CMake build directory. Refusing to automatically delete files in this directory. Delete the directory manually to 'clean' it.
neo@neo-server:~/ramses_esp$ rm -Rf build/
neo@neo-server:~/ramses_esp$ idf.py menuconfig

Zelfde error op zowel macos als debian. Heb even geen Windows voorhanden.

Ik zit het hier nu juist op windows te doen ;-)
Maar ik zie wel echt iets anders:

code:

C:\Users\Tom\github\temp>git clone https://github.com/IndaloTech/ramses_esp
Cloning into 'ramses_esp'...
remote: Enumerating objects: 1693, done.
remote: Counting objects: 100% (419/419), done.
remote: Compressing objects: 100% (42/42), done.
remote: Total 1693 (delta 382), reused 393 (delta 372), pack-reused 1274 (from 1)
Receiving objects: 100% (1693/1693), 5.85 MiB | 14.48 MiB/s, done.
Resolving deltas: 100% (1034/1034), done.

C:\Users\Tom\github\temp>cd ramses_esp

C:\Users\Tom\github\temp\ramses_esp>idf.py set-target esp32s3
Adding "set-target"'s dependency "fullclean" to list of commands with default set of options.
Executing action: fullclean
Build directory 'C:\Users\Tom\github\temp\ramses_esp\build' not found. Nothing to clean.
Executing action: set-target
Set Target to: esp32s3, new sdkconfig will be created.
Running cmake in directory C:\Users\Tom\github\temp\ramses_esp\build
Executing "cmake -G Ninja -DPYTHON_DEPS_CHECKED=1 -DPYTHON=C:\Espressif\python_env\idf5.2_py3.11_env\Scripts\python.exe -DESP_PLATFORM=1 -DIDF_TARGET=esp32s3 -DCCACHE_ENABLE=1 C:\Users\Tom\github\temp\ramses_esp"...
-- Found Git: C:/Espressif/tools/idf-git/2.44.0/cmd/git.exe (found version "2.44.0.windows.1")
-- ccache will be used for faster recompilation
-- The C compiler identification is GNU 13.2.0
-- The CXX compiler identification is GNU 13.2.0
-- The ASM compiler identification is GNU
-- Found assembler: C:/Espressif/tools/xtensa-esp-elf/esp-13.2.0_20230928/xtensa-esp-elf/bin/xtensa-esp32s3-elf-gcc.exe
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Espressif/tools/xtensa-esp-elf/esp-13.2.0_20230928/xtensa-esp-elf/bin/xtensa-esp32s3-elf-gcc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Espressif/tools/xtensa-esp-elf/esp-13.2.0_20230928/xtensa-esp-elf/bin/xtensa-esp32s3-elf-g++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Building ESP-IDF components for target esp32s3
Dependencies lock doesn't exist, solving dependencies.
.Updating lock file at C:\Users\Tom\github\temp\ramses_esp\dependencies.lock
Processing 1 dependencies:
[1/1] idf (5.2.1)
-- Project sdkconfig file C:/Users/Tom/github/temp/ramses_esp/sdkconfig
Loading defaults file C:/Users/Tom/github/temp/ramses_esp/sdkconfig.defaults...
C:/Users/Tom/github/temp/ramses_esp/sdkconfig.defaults:20 CONFIG_TCPIP_TASK_AFFINITY_CPU0 was replaced with CONFIG_LWIP_TCPIP_TASK_AFFINITY_CPU0
C:/Users/Tom/github/temp/ramses_esp/sdkconfig.defaults:21 CONFIG_TCPIP_TASK_AFFINITY was replaced with CONFIG_LWIP_TCPIP_TASK_AFFINITY
-- Compiler supported targets: xtensa-esp-elf
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of time_t
-- Check size of time_t - done
-- Found Python3: C:/Espressif/python_env/idf5.2_py3.11_env/Scripts/python.exe (found version "3.11.2") found components: Interpreter
-- Performing Test C_COMPILER_SUPPORTS_WFORMAT_SIGNEDNESS
-- Performing Test C_COMPILER_SUPPORTS_WFORMAT_SIGNEDNESS - Success
-- App "ramses_esp" version: 0.4.9
-- Adding linker script C:/Users/Tom/github/temp/ramses_esp/build/esp-idf/esp_system/ld/memory.ld
-- Adding linker script C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_system/ld/esp32s3/sections.ld.in
-- Adding linker script C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_rom/esp32s3/ld/esp32s3.rom.ld
-- Adding linker script C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_rom/esp32s3/ld/esp32s3.rom.api.ld
-- Adding linker script C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_rom/esp32s3/ld/esp32s3.rom.libgcc.ld
-- Adding linker script C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_rom/esp32s3/ld/esp32s3.rom.newlib.ld
-- Adding linker script C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_rom/esp32s3/ld/esp32s3.rom.version.ld
-- Adding linker script C:/Espressif/frameworks/esp-idf-v5.2.1/components/soc/esp32s3/ld/esp32s3.peripherals.ld
-- Components: app_trace app_update bootloader bootloader_support bt cc1101 cmock command console cxx driver efuse esp-tls esp_adc esp_app_format esp_bootloader_format esp_coex esp_common esp_eth esp_event esp_gdbstub esp_hid esp_http_client esp_http_server esp_https_ota esp_https_server esp_hw_support esp_lcd esp_local_ctrl esp_mm esp_netif esp_netif_stack esp_partition esp_phy esp_pm esp_psram esp_ringbuf esp_rom esp_system esp_timer esp_wifi espcoredump esptool_py fatfs frame freertos gateway hal heap http_parser idf_test ieee802154 json log lwip main mbedtls message mqtt newlib nvs_flash nvs_sec_provider openthread partition_table perfmon protobuf-c protocomm pthread ramses-debug ramses-led ramses-mqtt ramses-network ramses-nvs sdmmc soc spi_flash spiffs tcp_transport touch_element ulp unity usb vfs wear_levelling wifi_provisioning wpa_supplicant xtensa
-- Component paths: C:/Espressif/frameworks/esp-idf-v5.2.1/components/app_trace C:/Espressif/frameworks/esp-idf-v5.2.1/components/app_update C:/Espressif/frameworks/esp-idf-v5.2.1/components/bootloader C:/Espressif/frameworks/esp-idf-v5.2.1/components/bootloader_support C:/Espressif/frameworks/esp-idf-v5.2.1/components/bt C:/Users/Tom/github/temp/ramses_esp/components/cc1101 C:/Espressif/frameworks/esp-idf-v5.2.1/components/cmock C:/Users/Tom/github/temp/ramses_esp/components/command C:/Espressif/frameworks/esp-idf-v5.2.1/components/console C:/Espressif/frameworks/esp-idf-v5.2.1/components/cxx C:/Espressif/frameworks/esp-idf-v5.2.1/components/driver C:/Espressif/frameworks/esp-idf-v5.2.1/components/efuse C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp-tls C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_adc C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_app_format C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_bootloader_format C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_coex C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_common C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_eth C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_event C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_gdbstub C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_hid C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_http_client C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_http_server C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_https_ota C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_https_server C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_hw_support C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_lcd C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_local_ctrl C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_mm C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_netif C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_netif_stack C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_partition C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_phy C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_pm C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_psram C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_ringbuf C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_rom C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_system C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_timer C:/Espressif/frameworks/esp-idf-v5.2.1/components/esp_wifi C:/Espressif/frameworks/esp-idf-v5.2.1/components/espcoredump C:/Espressif/frameworks/esp-idf-v5.2.1/components/esptool_py C:/Espressif/frameworks/esp-idf-v5.2.1/components/fatfs C:/Users/Tom/github/temp/ramses_esp/components/frame C:/Espressif/frameworks/esp-idf-v5.2.1/components/freertos C:/Users/Tom/github/temp/ramses_esp/components/gateway C:/Espressif/frameworks/esp-idf-v5.2.1/components/hal C:/Espressif/frameworks/esp-idf-v5.2.1/components/heap C:/Espressif/frameworks/esp-idf-v5.2.1/components/http_parser C:/Espressif/frameworks/esp-idf-v5.2.1/components/idf_test C:/Espressif/frameworks/esp-idf-v5.2.1/components/ieee802154 C:/Espressif/frameworks/esp-idf-v5.2.1/components/json C:/Espressif/frameworks/esp-idf-v5.2.1/components/log C:/Espressif/frameworks/esp-idf-v5.2.1/components/lwip C:/Users/Tom/github/temp/ramses_esp/main C:/Espressif/frameworks/esp-idf-v5.2.1/components/mbedtls C:/Users/Tom/github/temp/ramses_esp/components/message C:/Espressif/frameworks/esp-idf-v5.2.1/components/mqtt C:/Espressif/frameworks/esp-idf-v5.2.1/components/newlib C:/Espressif/frameworks/esp-idf-v5.2.1/components/nvs_flash C:/Espressif/frameworks/esp-idf-v5.2.1/components/nvs_sec_provider C:/Espressif/frameworks/esp-idf-v5.2.1/components/openthread C:/Espressif/frameworks/esp-idf-v5.2.1/components/partition_table C:/Espressif/frameworks/esp-idf-v5.2.1/components/perfmon C:/Espressif/frameworks/esp-idf-v5.2.1/components/protobuf-c C:/Espressif/frameworks/esp-idf-v5.2.1/components/protocomm C:/Espressif/frameworks/esp-idf-v5.2.1/components/pthread C:/Users/Tom/github/temp/ramses_esp/components/ramses-debug C:/Users/Tom/github/temp/ramses_esp/components/ramses-led C:/Users/Tom/github/temp/ramses_esp/components/ramses-mqtt C:/Users/Tom/github/temp/ramses_esp/components/ramses-network C:/Users/Tom/github/temp/ramses_esp/components/ramses-nvs C:/Espressif/frameworks/esp-idf-v5.2.1/components/sdmmc C:/Espressif/frameworks/esp-idf-v5.2.1/components/soc C:/Espressif/frameworks/esp-idf-v5.2.1/components/spi_flash C:/Espressif/frameworks/esp-idf-v5.2.1/components/spiffs C:/Espressif/frameworks/esp-idf-v5.2.1/components/tcp_transport C:/Espressif/frameworks/esp-idf-v5.2.1/components/touch_element C:/Espressif/frameworks/esp-idf-v5.2.1/components/ulp C:/Espressif/frameworks/esp-idf-v5.2.1/components/unity C:/Espressif/frameworks/esp-idf-v5.2.1/components/usb C:/Espressif/frameworks/esp-idf-v5.2.1/components/vfs C:/Espressif/frameworks/esp-idf-v5.2.1/components/wear_levelling C:/Espressif/frameworks/esp-idf-v5.2.1/components/wifi_provisioning C:/Espressif/frameworks/esp-idf-v5.2.1/components/wpa_supplicant C:/Espressif/frameworks/esp-idf-v5.2.1/components/xtensa
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/Tom/github/temp/ramses_esp/build

Ik zie in jouw output helemaal geen CMake en geen "Executing action: set-target". Het moet echt eindigen met: "Build files have been written to: ..."


Ik denk dat je die build dir weg moet gooien en dan nog eens set-target:

code:

rm -Rf build/
idf.py set-target esp32s3
idf.py menuconfig

[Verwijderd]

Ach wat ben ik ook een gup, ik heb de set-target en de rm van de build omgedraaid. Dacht ik ben secuur, iets té secuur... Alles weg incl de set target die natuurlijk files aanmaakt in de build dir.

Thanks ik ga even prutsen!

[ Voor 20% gewijzigd door Verwijderd op 30-12-2024 15:55 ]

[RudolfR]

Maintainer van ramses_cc houdt er mee op en zoekt een nieuwe code owner:

https://github.com/zxdavb...97ac436893c690e2650121317

[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.

[RVerheijden]

Iemand anders ook issue met ramses_cc in Homeassistant sinds de laatste update.
Home Assistant 2025.3.
Bij mij start de integratie niet meer.
En de beheerder van deze integratie geeft aan geen tijd meer te hebben om dit project te onderhouden.
Heb voor niet dus de laatste februarie versie weer terug gezet.

[Onl1ne1373]

Ik draai Home Assistant 2025.3.0 met Ramses RF 0.50.1 zonder problemen. Wat voor foutmelding kreeg je in de log?

Wel balen dat hij er mee stopt!

[Churitos]

Ik had hetzelfde probleem.
Onderstaande link van de Github geeft oplossing:
https://github.com/zxdavb/ramses_cc/issues/235

[XElD]

Idem hier, Ramses CC weer werkend. Ik was er even niet aan toegekomen om er eerder naar te kijken.

Vraag me wel af of er iemand is met voldoende programmeer ervaring die de ramses repo wil overnemen. Want op deze wijze is het natuurlijk gewoon een kwestie van tijd voordat de boel het begeeft in HA.

[golfdiesel]

Ik ben bang dat het zo'n niche toepassing is dat er maar weinig mensen zulllen zijn die hier interesse in hebben.
Het blijft jammer dat Honeywell geen locale API beschikbaar stelt.

[Verwijderd]

.

[ Voor 107% gewijzigd door Verwijderd op 29-08-2025 19:18 ]

[sparretje]

Hallo ik heb een bordje gekocht bij vliegnerd ik heb hem in ha staan ik kan alles uitlezen maar ik wil mijn orcon hrc 300 ecomax uit 2024 bedienen bypass standen enzo alleen dat lukt mij nog niet

Alvast bedankt

[vliegnerd]

sparretje schreef op woensdag 4 juni 2025 @ 11:47:
Hallo ik heb een bordje gekocht bij vliegnerd ik heb hem in ha staan ik kan alles uitlezen maar ik wil mijn orcon hrc 300 ecomax uit 2024 bedienen bypass standen enzo alleen dat lukt mij nog niet

In de startpost van Het grote Orcon HRC / WtW topic staat een handleiding om ramses_cc te installeren en je Orcon WTW te bedienen.

Als je daar start, dan kunnen we je in dat topic ook verder helpen. Succes!

[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

[vliegnerd]

Dank @Kriseh!!

Het zijn de bordjes die eerder in dit topic beschreven zijn. Op basis esp32s3 zero of esp32c3 mini. Draait niet de stock ramses_esp firmware, maar wel met minimale aanpassingen.

Het gaat om dit bordje: https://github.com/tomkooij/e07-900m10s-esp32s3zero
in deze repo staan alle Kicad + gerber bestanden die je nodig hebt om het bordje te laten maken bij bijvoorbeeld JLCPCB. e07-900m10s module erop solderen en klaar. Tegenwoordig zijn die dingen betrouwbaar te koop via Aliexpress (verkoper ebyte/cdebyte).

De aanpassing van de partitiontabel staat in deze repo: https://github.com/tomkooij/ramses_esp_esp32s3mini
Als partition.csv er zo uitziet:

code:

# ESP-IDF Partition Table
# Name,   Type, SubType, Offset,  Size, Flags
nvs,      data, nvs,     0x9000,  64K,
otadata,  data, ota,     0x19000, 8K,
phy_init, data, phy,     0x1B000, 4K,
ota_0,    app,  ota_0,   ,        1920K,
ota_1,    app,  ota_1,   ,        1920K,

Dan werkt OTA update ook voor 4Mb flash modules, zoals de esp32s3zero. Je moet dan natuurlijk wel een update vanuit je eigen (of mijn) repo doen, want de stock firmware draait hier niet op.

Voor de esp32c3 mini is er dit bordje: https://github.com/tomkooij/promicro-cc1101
En de firmware: https://github.com/tomkooij/ramses_esp_c3
Gebruik de "nowifi" branch als je wifi echt wil uitzetten. Zo gebruik ik ze: Alléén via USB-C bedraad aangesloten.
(Zie ook deze post eerder in de thread)

Mijn PCB voorraad is overigens op, dus ik kan ze voorlopig niet verkopen. Maar Indalotech verkoopt het origineel (goede kwaliteit, alleen duur vanwege invoerrechten) en je kunt ze echt eenvoudig in elkaar solderen: PCB bestellen bij JLCPCB, module + e07-900m10s en wat leds/weerstanden bij Aliexpress. Beetje flux erbij en dan moet het lukken.
Ik heb wel een idee voor een nieuw bordje om ESPHome te draaien, maar ja, veel plannen, weinig tijd.

[ Voor 11% gewijzigd door vliegnerd op 07-06-2025 13:47 ]

[Flexiilex]

Hi all,

Vraagje; hebben meer mensen last met de pre-release versie van Ramses_cc dat de data niet aankomt in HA en alleen als ik de plugin reload? De data van de WTW komt dus gewoon 1x aan aan en daarna niet meer. Totdat ik de Hacs plugin weer reload. Iemand enig idee waar dit aan kan liggen?

Het lukt mij overigens ook niet om de functie "Accept packets from known devices IDs only" aan te zetten. Dan zeurt de plugin om het volgende; "LookupError: Can't create 32:157263: it is in the schema, but not in the known_list (check the lists and the schema)"

Enige is, deze staat helemaal niet in de schema of known list.. Heel raar.

Edit: SNTP, TimeZone & Wi-Fi geconfigureerd. Nu werkt alles, behalve de "Accept packets from known devices IDs only" setting. Iemand nog een idee?

[ Voor 95% gewijzigd door Flexiilex op 10-06-2025 12:46 ]

[BazemanKM]

vliegnerd schreef op zaterdag 7 juni 2025 @ 13:42:
Ik heb wel een idee voor een nieuw bordje om ESPHome te draaien, maar ja, veel plannen, weinig tijd.

Zodat je hem via WiFi kunt configureren en hij daarna verbinding kan maken met de MQTT broker? Ethernet zou ook fijn zijn.

Zou top zijn en is iets vergelijkbaars als https://www.tindie.com/pr...shamon-communication-pcb/.

Misschien kun je het via Tindie verkopen?

Hoop dat je de tijd vindt.

[vliegnerd]

BazemanKM schreef op maandag 9 juni 2025 @ 23:34:
[...]

Zodat je hem via WiFi kunt configureren en hij daarna verbinding kan maken met de MQTT broker? Ethernet zou ook fijn zijn.

Vooral zodat je eenvoudig een WTW kunt uitlezen en besturen (Fan standen, bypass, filtertijd), zonder het "gedoe" van het configureren van ramses_cc. Daarmee kan *VEEL* meer. En ramses ESP is ook beter in het ontvangen van RF berichten dan wat simpele code in ESPHome, maar de leercurve moet erg steil zijn om niet helemaal te verzuipen in het configureren.

Dus niet alle mogelijkheden maar gewoon iets om simpel een Orcon of Itho WTW uit te lezen/bedienen. Maar dan wel "plug and play".

[BazemanKM]

vliegnerd schreef op dinsdag 10 juni 2025 @ 20:31:
[...]


Vooral zodat je eenvoudig een WTW kunt uitlezen en besturen (Fan standen, bypass, filtertijd), zonder het "gedoe" van het configureren van ramses_cc. Daarmee kan *VEEL* meer. En ramses ESP is ook beter in het ontvangen van RF berichten dan wat simpele code in ESPHome, maar de leercurve moet erg steil zijn om niet helemaal te verzuipen in het configureren.

Dus niet alle mogelijkheden maar gewoon iets om simpel een Orcon of Itho WTW uit te lezen/bedienen. Maar dan wel "plug and play".

En Evohome? Daar heb ik vooral behoefte aan ;-)

[vliegnerd]

BazemanKM schreef op dinsdag 10 juni 2025 @ 22:22:
[...]

En Evohome? Daar heb ik vooral behoefte aan ;-)

Nee voor evohome is Ramses ESP met Ramses_cc in HA juist heel geschikt.

[Kriseh]

Flexiilex schreef op maandag 9 juni 2025 @ 12:35:
Hi all,

Vraagje; hebben meer mensen last met de pre-release versie van Ramses_cc dat de data niet aankomt in HA en alleen als ik de plugin reload? De data van de WTW komt dus gewoon 1x aan aan en daarna niet meer. Totdat ik de Hacs plugin weer reload. Iemand enig idee waar dit aan kan liggen?

Het lukt mij overigens ook niet om de functie "Accept packets from known devices IDs only" aan te zetten. Dan zeurt de plugin om het volgende; "LookupError: Can't create 32:157263: it is in the schema, but not in the known_list (check the lists and the schema)"

Enige is, deze staat helemaal niet in de schema of known list.. Heel raar.

Edit: SNTP, TimeZone & Wi-Fi geconfigureerd. Nu werkt alles, behalve de "Accept packets from known devices IDs only" setting. Iemand nog een idee?

Ik heb dat 'Accept packets from known device IDs only" probleem ook. Dit lijkt een bug te zijn: https://github.com/zxdavb/ramses_cc/issues/202. Doordat de repo owner er mee is gestopt, denk ik niet dat dit (op korte termijn) nog gefixt wordt.

Het lukt me daarnaast ook niet om m'n eigen schema te bouwen, ik blijf ook dan foutmeldingen krijgen.

[ Voor 4% gewijzigd door Kriseh op 14-06-2025 09:02 ]

[golfdiesel]

Ik hoop wel dat er nog iemand opstaat om de Repo over te nemen.
Anders kan het wel eens snel afgelopen zijn met de support voor Ramses in HomeAssistant.

[nvd1900]

Heeft iemand hier ervaring met een goede voeding voor een Indalo‐Tech RAMSES_ESP? Ik heb inmiddels al diverse geprobeerd met verschillende wattages maar elke 10 a 15 minuten reboot het apparaat en verbind het opnieuw met de wifi / MQTT.
Of kan dit wellicht er mee te maken hebben dat er in een nieuwbouwwijk die vol staat met Itho / Orcon spul het apparaat overbelast raakt?

[golfdiesel]

Ik kan mij niet voorstellen dat de voeding erg kritisch is voor een ESP32 gebaseerd ding.
Er zal waarschijnlijk iets anders aan de hand zijn.

[kimjansen]

nvd1900 schreef op woensdag 9 juli 2025 @ 21:32:
...elke 10 a 15 minuten reboot het apparaat en verbind het opnieuw...

Volgens mij heb ik al een hele tijd precies hetzelfde, alleen nog niet naar een mogelijke oorzaak kunnen kijken...

[ebroerse]

Voor de toekomst van de ramses_rf lib heb ik als vrijwilliger/hobbyprogrammeur het beheer overgenomen van zxdavb. In ons huis regel ik met ramses_cc via HA de ventilatie (Vasco, ClimaRad) dus het leek me de moeite waard.

Op GitHub is alles verhuisd naar ramses-rf. Bestaande installaties en HACS zouden automatisch doorverwezen moeten worden. Mss even de browser cache legen en als je de code hebt gekloond, in je IDE de remote aanpassen.

Dit lijkt me een actief forum voor NL gebruikers.
Met hulp van jullie medegebruikers kunnen we er vast nog meer mee. Meld je issues graag zelf in GitHub (met packet logs en info over types en alles wat je verder opvalt, 1 onderwerp per issue - dan kunnen we het ook apart bekijken).
PR’s zijn ook welkom!

Egbert

[golfdiesel]

Dat is goed nieuws Egbert! Dankjewel dat je het overgenomen hebt!

[XElD]

Mooi om te horen Egbert, top!

Weet ik dat het zin heeft me verder te verdiepen in commados die m'n Orcon HRC snapt :-)

[Kriseh]

Wat gaaf Egbert!

Zelf last van deze issue: https://github.com/ramses-rf/ramses_cc/issues/202. Ik weet niet zo goed hoe Github werkt, dus ik zie wel fixes en discussies voorbijkomen maar geen nieuwe ramses_CC release o.i.d. dus volgens mij moet ik gewoon even geduldig afwachten.

Daarnaast heb ik een aantal Honeywell TRVs, normaliter beginnen die met serie no. 04: en ik heb er één tussenzitten die met 63: begint. Voor die laatste vindt geen auto device type mapping plaats. Ik kan dan wel mijn eigen schema bouwen in HA maar als de auto-mapping-functionaliteit dit oppakt is dat beter denk ik. Ik zie dan wel dat die definities hier in staan: ramses_rf/src/ramses_tx/const.py maar geen idee wat er allemaal aangepast moet worden. Moet ik hiervoor dan onder Rames_RF (i.p.v. Ramses_CC) een Github 'issue' aanmaken?

[Wimpie70]

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.

[ebroerse]

Ik hoop over ca. 1 week een nieuwe ramses release te maken.
De ramses_cc custom integration die je in HA kan installeren, werkt achter de schermen met een 2e stuk python-code: ramses_rf, en die moet tegelijk bijgewerkt worden.

Als HA gebruiker is het prima om een evt. nieuw issue op ramses_cc aan te maken (graag eerst even met de zoekfunctie checken of het al is gemeld, kan al afgesloten zijn). Tenzij de foutmelding naar ramses_rf verwijst.

[ebroerse]

In het Ramses-II protocol hebben niet alle apparaten een vaste type-code. Volgens mij alleen CH (verwarming).
Voor HVAC (klimaat/ventilatie) hebben fabrikanten allerlei modellen ontwikkeld, maar die zijn niet aan het eerste deel van hun device_id te herkennen.
Daarom moet je hun class zelf labellen in je known_devices list.
Apparaten die zich niet (vaak genoeg) melden bij je gateway zet je onder “orphans_hvac:” in je Systeemschema.

[Wimpie70]

Wat nog wat verwarrend kan zijn:
- ramses_rf verzorgd de basis, platform onafhankelijk
- ramses_cc is het gedeelte wat je als integratie installeerd bij HA, maar wordt ramses RF genoemd.

ramses_rf wordt automatisch geinstalleerd als dependency van ramses_cc (ramses RF)

[Verwijderd]

De naamgeving kon duidelijker idd

Mocht je met de python-lib aan de gang gaan: https://github.com/sandervandegeijn/OrconRamsesRFCommand

Ik heb destijds de Orcon commands uitgeplozen. Misschien wat om te integreren.

[Wimpie70]

ahh, ok, ik heb het bijna geintegreerd, zie het grote Orcon...

[Hippe Lip]

Een tijdje geleden was ik begonnen aan die Ramses-integratie, maar heb dat toen wegens tegenvallers en gebrek aan tijd nooit afgemaakt.

Nu probeer ik het weer op te pakken, maar er gaat van alles mis. Dus dacht ik: ik verwijder de integratie en begin van scratch af aan opnieuw. Maar dat lukt helemaal niet. Bij Instellingen > Apparaten en diensten tik ik op Ramses RF en dan op de regel Rases RF tik ik op de 3 puntjes, rechts van het tandwieltje. Dan kies ik voor ‘Verwijderen’. Dan komt er een popup die me vraagt
RAMSES RF verwijderen?
De bijbehorende apparaten en entiteiten worden permanent verwijderd.[/quote]
[quote]
Dan druk ik op Verwijderen, maar na een herstart van HA staat Ramses RF nog vrolijk in het rijtje van de Apparaten en diensten.

Hoe kan ik die integratie verwijderen om werkelijk van nul af aan opnieuw te beginnen?
Ik heb van alles geprobeerd, waaronder het verwijderen van alle ca. 50 entiteiten, maar dat heeft ook niet geholpen.

Edit:
Inmiddels ven ik een stap verder. Om te verwijderen moest ik eerst bij Instellingen > Apparaten en Diensten kiezen voor verwijderen en dan zonder herstart tussendoor bij HACS kiezen voor verwijderen. Nu is Ramses niet meer te zien bij Apparaten en niet bij HACS, ook niet na een herstart.
Maar als HA mijn configuratie controleert, dan zegt-ie nog steeds

Integration error: ramses_cc - Integration 'ramses_cc' not found.

Ook na een herstart. Er zit dus nog steeds ergens een stuk Ramses.
Waar?
Hoe krijg ik dat weg?

[ Voor 28% gewijzigd door Hippe Lip op 04-08-2025 01:23 ]

[Wimpie70]

Ik kan niet zien hoe je systeem in elkaar zit, dus wees voorzichtig bij de volgende tips en maak eerst een backup.
Bekijk je home-assistant.log bestand. Misschien staan hier aanwijzingen in wat er aan de hand is.
Misschien is er nog een script, automation of card die iets van Ramses probeerd op te vragen...
Is het een fout van HACS of van HA ? Heb je meer integraties via HACS geinstalleerd ? anders zou je kunnen proberen om HACS opnieuw te installeren.
Ook kan je proberen om eerst ramses RF opnieuw te installeren.

Het zou kunnen dat er nog devices of entities van Ramses zijn achtergebleven. Probeer deze vanuit HA te verwijderen.
Als dat niet lukt, kan je nog de .config map bekijken (hidden?) in je HA folder: core.entity_registry en core.device_registry. Maar maak dan eerst een backup. En stop HA voordat je hier iets aan veranderd. Dit kan HA behoorlijk in de soep laten lopen dus voorzichtig.

[ebroerse]

Verwijderd schreef op zondag 3 augustus 2025 @ 09:08:
De naamgeving kon duidelijker idd

Mocht je met de python-lib aan de gang gaan: https://github.com/sandervandegeijn/OrconRamsesRFCommand

Ik heb destijds de Orcon commands uitgeplozen. Misschien wat om te integreren.

Ik kwam die laatst ook tegen en heb er een ster bij gezet. Maar OrconRamsesRFCommand heeft niets met “Ramses RF” (ramses_rf/ramses_cc), al doet zijn Readme anders vermoeden. Net als ramses_rf praat OrconRamsesRFCommand met een ramses_esp dongle, maar alleen via MQTT. Al deze programma’s praten daarbij het Honeywell Ramses-II RF protocol op 868MHz (dat heet geen WiFi, RF = radio frequency).

[ Voor 3% gewijzigd door ebroerse op 05-08-2025 07:01 ]

[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 ]

[Wimpie70]

Ik vermoed dat je de HGI niet in de known list hebt staan. En 'Configuratie-item' zal wel een vertaling zijn van 'config-flow'. Ik draai zelf de engelse versie.
Als je op de config klikt (tandwieltje) van ramses RF, dan kan je bij 1 van de opties 'System schema and known devices'. Hier kun je de 'known list'/'Known device IDs' en 'orphans' instellen. Hier moet bij de known devices 1 HGI staan. Zoiets als:

code:

"18:149488":
  class: HGI
"29:176861":
  class: REM
"32:153289":
  class: FAN
"37:126776":
  class: CO2

Maar dan voor jouw devices.
Voor jou lijkt dit: 18:104436 te zijn (of van je buren)
De log in HA geeft niet zo heel veel info. Het log bestand home-assistant.log geeft meer. Vooral als je de debug voor ramses aanzet in je configuration.yaml:

code:

logger:
  default: info
  logs:
    custom_components.ramses_cc: debug
    ramses_rf: debug
    ramses_tx: debug

Kijk in het logbestand naar Warning of andere berichten die aangeven waarom het niet werkt.
Er wordt momenteel hard gewerkt aan een nieuwe release die een aantal van de foutmeldingen die je nu tegenkwam zal oplossen. Maar ik denk dat het bij jouw installatie aan de instellingen ligt.

[ebroerse]

Hippe Lip schreef op dinsdag 5 augustus 2025 @ 12:33:
…
Kan iemand me op weg helpen?

…

Nou zoek ik me ROT wat dat ‘Configuratie-item’ is. Wie o wie kan me helpen?

Goede tips al.
Pak ook de recent bijgewerkte wiki er gerust bij.

De debug log kan je in het Integratie-scherm (Instellingen > Integraties > Ramses RF VIA DE 3 puntjes rechtsboven in- en uitschakelen. Op een PC komt het log in mijn Download map zodra je hem uitzet.

[Hippe Lip]

Dank allemaal voor het meedenken. De oplossing bleek (zoals wel vaker) erg eenvoudig. Het was alleen niet eenvoudig die te vinden.

Wat de oplossing bracht (ik heb het systeem nu ook maar op Engels ingesteld):

1. Settings > Devices > Ramses
2. Tik op drie puntjes naast tandwieltje, rechts op regel RAMSES RF
3. Tik op ‘Disable’
4. Restart HA
5. Settings > Devices > Ramses
6. Tik op drie puntjes naast tandwieltje, rechts op regel RAMSES RF
7. Tik op ‘Enable’
8. Restart HA

Et voila: alles werkt

En waarom het eerst niet werkte en de boel eerst disabled moest worden? Op de een of andere manier bleef het disabled staan, ondanks dat het op enabled stond. Maar ja, voordat je dáár achter bent…

[Wimpie70]

Dat verwacht je niet, mooi dat t weer werkt!
Tof, die vernieuwde wiki

[ebroerse]

Er is een nieuwe release v0.51.0 van de Ramses RF integratie beschikbaar (in HACS en op GitHub).

[Hippe Lip]

ebroerse schreef op zaterdag 9 augustus 2025 @ 16:04:
Er is een nieuwe release v0.51.0 van de Ramses RF integratie beschikbaar (in HACS en op GitHub).

En heeft iemand die al geïmplementeerd en goed bevonden? Ik kom net terug van een herstelfunctie van een de update van een andere integratie, waardoor de boel niet meer werkte. Veel gedoe en missende historie daardoor helaas…

[Wimpie70]

Ik heb andere hardware dan jij, maar wat ik tot nu toe heb gezien bij een Orcon WTW werkt het prima. Ik heb niet alle veranderingen bekeken, maar volgens mij heeft Egbert een prima job gedaan. Er zijn een flink aantal issues aangepakt en code is gemoderniseerd.

Sowieso is het verstandig om een backup te maken voordat je iets nieuws installeerd. Als je nog wat meer zekerheid wilt, kan je het ook eerst bijvoorbeeld in een docker container testen. Maar dat heb ik voor de nieuwe versie nog niet zelf gedaan.

Ik heb hem op m'n productie HA via HACS geupgrade...
Bij HACS, menu rechtsboven met drie puntjes, via custom repositories ingevuld, De URL is veranderd naar: https://github.com/ramses-rf/ramses_cc (integratie) en daarna kon ik versie 0.51.0 van RAMSES RF downloaden.
Na herstart geen echte problemen, wat warnings en time-outs. Die zal ik als ik wat meer tijd heb nog eens goed bekijken.

Je kan natuurlijk ook even wachten tot er meer mensen hebben getest...maar feedback van eventuele issues is uiteraard ook zeer welkom.

[Swazija]

Ik heb 0.51.0 geinstalleerd gisteren en heb 3 kleine bugs:

1. Exhaust fan speed percentage geeft me waardes die veel te klein zijn. Lijkt een factor 10 te missen ofzo.
2. Bypass sluiten zorgt ervoor dat de status van de bypass unavailable wordt ipv off
3. Een 10D0 request (RQ --- 37:123456 32:123456 --:------ 10D0 001 00) geeft een packet invalid en ook de waarde voor filter remaining blijft op unavailable staan. Voor de update werkte dit zonder problemen

[ebroerse]

Swazija schreef op maandag 11 augustus 2025 @ 12:27:
Ik heb 0.51.0 geinstalleerd gisteren en heb 3 kleine bugs:

1. Exhaust fan speed percentage geeft me waardes die veel te klein zijn. Lijkt een factor 10 te missen ofzo.
2. Bypass sluiten zorgt ervoor dat de status van de bypass unavailable wordt ipv off
3. Een 10D0 request (RQ --- 37:123456 32:123456 --:------ 10D0 001 00) geeft een packet invalid en ook de waarde voor filter remaining blijft op unavailable staan. Voor de update werkte dit zonder problemen

Bedankt voor de melding. Item 2 staat al als Issue in op GitHub en heb ik hopelijk al een fix voor. Wil je voor de andere 2 ook issues maken, met de Bug template en vermelding van je config (merk fan en receiver) en een kopie van je foutenlog? Is wel een GitHub account voor nodig, maar ik zou de moeite op prijs stellen

[Swazija]

Ik heb twee bug reports aangemaakt.

[ebroerse]

Ramses RF 0.51.3 is uit, mss al gezien in HACS.
- Sensors verdwijnen niet meer doordat een ander packet ze wist.
- En de integratie herkent als de MQTT verbinding weer hersteld is, geen reset meer vereist, bedankt @immrmkw
Er zijn nog geen nieuwe sensors zichtbaar in HA, want de tests blijken niet heel stabiel. Weer een nieuwe cursusje aan het doen😲

Dank voor jullie bug reports.

[ebroerse]

Ramses RF 0.51.4 is uit, met nieuwe sensors in HA (bedoeld voor bepaalde Vasco, ClimaRad & Itho ventilatoren).

[ebroerse]

Ramses RF v0.51.5 is uit.
Naast wat nieuwe opties is het instellen van de seriële poort gefixt, met dank aan @immrmkw

[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.

[XElD]

ebroerse schreef op zondag 7 september 2025 @ 22:19:
Ramses RF v0.51.5 is uit.
Naast wat nieuwe opties is het instellen van de seriële poort gefixt, met dank aan @immrmkw

Top, ga 'm eens snel uitproberen

Ondertussen ook met iets anders begonnen. Ik ga m'n Zigbee coördinator thuis voor andere HA zaken vervangen door een SMLight coördinator, dus via Ethernet. Nu hebben ze zeer recent een versie geintroduceerd met 'USB passtrough', d.w.z. dat je er een USB stick op kan aansluiten en dat die dan via het netwerk benaderbaar zou moeten zijn.

https://smlight.tech/product/slzb-mr1u

Nu heb ik zelf een SSM-D2 USB stick dus ben benieuwd of dat hiermee zou gaan werken.

[ebroerse]

JoepW schreef op maandag 8 september 2025 @ 10:26:
…wat het juiste format is voor known devices voor mijn Evohome ramses_cc opzet. Ik kom er niet echt uit...

Zie hint bij je crosspost in het HA Users Forum.

[JoepW]

ebroerse schreef op dinsdag 9 september 2025 @ 10:35:
[...]

Zie hint bij je crosspost in het HA Users Forum.

Ik heb daar extra info gepost nog steeds op zoek naar het juiste format.

[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)

[ebroerse]

Kriseh schreef op zaterdag 13 september 2025 @ 16:37:
[...]
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.

Schijnt vaker voor te komen, zie het engelstalige HA forum. Alles wat Ramses RF oppikt, komt uit je instellingen in de Evohome? Centrale. Namen van kamers, koppeling met ‘parent’ radiatoren. Ik lees dat je daar ook deze fout moet fixen: zie bijv. deze discussie

[Kriseh]

ebroerse schreef op zaterdag 13 september 2025 @ 21:30:
[...]


Schijnt vaker voor te komen, zie het engelstalige HA forum. Alles wat Ramses RF oppikt, komt uit je instellingen in de Evohome? Centrale. Namen van kamers, koppeling met ‘parent’ radiatoren. Ik lees dat je daar ook deze fout moet fixen: zie bijv. deze discussie

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!