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/zelfbouw: vliegnerd in "Ramses II 868MHz communicatie via evofw3 en ramses_rf"

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 57% gewijzigd door vliegnerd op 14-08-2024 15:09 . 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 ]

[maleadt]

Het is mij ook gelukt om evofw3 op een nanoCUL te flashen, dus ik documenteer het hier even.

Mijn nanoCUL komt van https://schlauhaus.biz/en/product/nanocul-868/, bevat dus een ATMEGA328P (en geen 32u4 zoals in https://github.com/ghoti57/evofw3/issues/22 te lezen valt). Hierbij heb ik voor de culfw gekozen ("V 1.67 nanoCUL868", zoals ik kon uitlezen door "V" te sturen over serial terminal). Net zoals vliegnerd hierboven heb ik de evofw3 sources gecompileerd met de Arduino IDE (met evofw3 board definitions ingeladen), met dezelfde settings (board "atmega328p (SW UART)", processor "atmega328p (5V, 16 MHz)", pinout "Nano", maar baudrate 115200). Omdat ik dfu-programmer niet in gang kreeg (op macOS werd geen device gedetecteerd, op Windows vond ik de drivers niet) heb ik dan maar gewoon avrdude gebruikt, want dat werkt blijkbaar gewoon:

code:

avrdude -p atmega328p -c arduino -P /dev/serial/by-id/usb-... -b 57600 -D -Uflash:w:./evofw3.ino.hex

In tegenstelling tot vliegnerd heeft mijn device dit wel overleefd Als ik een seriële terminal opstart, krijg ik na `!V` te sturen mooi `# evofw3 0.7.1` te zien. Momenteel aan het autotunen, dus hopelijk werkt alles (het kan nog zijn dat de pinout niet overeenkomt natuurlijk).

Ik had eigenlijk al een werkende Arduino Micro met CC11010 en evofw3 verbonden met ramses_rf, maar kon er enkel berichten mee ontvangen, niet verzenden. Vandaar dat ik het eens uitprobeer met een nanoCUL. Als dat ook niet lukt zal het waarschijnlijk een FanX worden, als die weer op voorraad is.

EDIT: en na het tunen kan ik met HA successvol commands versturen, en eindelijk de ventilatie (beter dan met een relais) sturen

[ Voor 4% gewijzigd door maleadt op 15-01-2023 22:34 ]

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

[vliegnerd]

blb4 schreef op zaterdag 18 maart 2023 @ 21:34:
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 gebruik ramses_rf (decoderen van ramses_ii zenden en ontvangen) en ramses_cc (Home Assistant integratie).
https://github.com/zxdavb/ramses_rf en https://github.com/zxdavb/ramses_cc
Maar waarschijnlijk heeft jouw evoGateway ook ramses_rf onder de motorkap.

De ontwikkelaar is zeer actief om nieuwe dingen toe te voegen en problemen te verhelpen. De itho WTW ondersteuning is wel redelijk af volgens mij. En evohome zou er ook goed ondersteunt in moeten zitten.

Kan mij voorstellen dat evohome <> warmtepomp wel weer een dingetje is.

[blb4]

vliegnerd schreef op zondag 19 maart 2023 @ 08:17:
[...]


Ik gebruik ramses_rf (decoderen van ramses_ii zenden en ontvangen) en ramses_cc (Home Assistant integratie).
https://github.com/zxdavb/ramses_rf en https://github.com/zxdavb/ramses_cc
Maar waarschijnlijk heeft jouw evoGateway ook ramses_rf onder de motorkap.

De ontwikkelaar is zeer actief om nieuwe dingen toe te voegen en problemen te verhelpen. De itho WTW ondersteuning is wel redelijk af volgens mij. En evohome zou er ook goed ondersteunt in moeten zitten.

Kan mij voorstellen dat evohome <> warmtepomp wel weer een dingetje is.

Klopt, evoGateway maakt ook gebruik van ramses_rf. Ik ben wel gecharmeerd van MQTT, ithowifi maakt daar ook direct gebruik van ipv usb/seriële koppeling, daar zit ik altijd wat mee te stoeien. Ik draai ook wel Home Assistent maar die draait in een docker container op een QNAP NAS en ik heb me er nog niet echt in verdiept hoe ik een USB poort aan die container kan toewijzen.
vandaar dat ik dus nu eerst met evoGateway aan de gang ga, ik heb nu alle berichten via MQTT en moet ‘t ook via MQTT kunnen aansturen. Uiteindelijk moet ‘t gaan samenwerken met de aansluiting van mijn warmtepomp die in NodeRed draait.

[blb4]

..

[ Voor 99% gewijzigd door blb4 op 19-03-2023 12:45 ]

[slow whoop]

Ik kende dit topic niet. Ik ben recentelijk met ramses_cc aan de slag gegaan en heb mijn eerste bevindingen in het Home Assistant topic neergezet, maar die waren hier misschien meer op z'n plaats geweest.

Het werkt bij mij prima. Dingen die me opgevallen zijn:

• Ik zie net zo makkelijk m'n eigen Evo devices als die van m'n buren. Ik zou dus ook hun thermostaten kunnen bedienen. Dat lijkt me op z'n zachtst gezegd niet wenselijk.
• De warmevraag (Heat demand) die ik per device zie komt niet overeen met wat ik op het display van m'n Evohome thermostaat zie staan. Ik snap niet goed waar die verschillen vandaan komen.

Edit: @blb4 Ik draai ook Home Assistant in een docker. In m'n docker-compose.yaml file heb ik het USB device gemapt naar /dev/ramses voor Home Assistant:

YAML:

home-assistant:
  [...]
  devices:
    - "/dev/ttyACM0:/dev/ramses"

Wel even uitzoeken welke USB port (ttyACMx of iets dergelijks) je gebruikt voor je evofw3 USB device.

Vervolgens heb ik het gemapte USB device weer toegevoegd in de configuration.yaml file voor ramses_cc:

YAML:

ramses_cc:
  serial_port: /dev/ramses
  [...]

[ Voor 26% gewijzigd door slow whoop op 30-03-2023 12:42 ]

[TheMystery]

slow whoop schreef op donderdag 30 maart 2023 @ 12:13:
Ik kende dit topic niet. Ik ben recentelijk met ramses_cc aan de slag gegaan en heb mijn eerste bevindingen in het Home Assistant topic neergezet, maar die waren hier misschien meer op z'n plaats geweest.

Het werkt bij mij prima. Dingen die me opgevallen zijn:

• Ik zie net zo makkelijk m'n eigen Evo devices als die van m'n buren. Ik zou dus ook hun thermostaten kunnen bedienen. Dat lijkt me op z'n zachtst gezegd niet wenselijk.
• De warmevraag (Heat demand) die ik per device zie komt niet overeen met wat ik op het display van m'n Evohome thermostaat zie staan. Ik snap niet goed waar die verschillen vandaan komen.

Edit: @blb4 Ik draai ook Home Assistant in een docker. In m'n docker-compose.yaml file heb ik het USB device gemapt naar /dev/ramses voor Home Assistant:

YAML:

home-assistant:
  [...]
  devices:
    - "/dev/ttyACM0:/dev/ramses"

Wel even uitzoeken welke USB port (ttyACMx of iets dergelijks) je gebruikt voor je evofw3 USB device.

Vervolgens heb ik het gemapte USB device weer toegevoegd in de configuration.yaml file voor ramses_cc:

YAML:

ramses_cc:
  serial_port: /dev/ramses
  [...]

Bedoel je de heat demand van een hr92 knop? Dit is niet echt heat demand maar de klep positie van de hr92.
Die zou overeen moeten komen als je deze opvraagt op de hr92.

[slow whoop]

TheMystery schreef op donderdag 30 maart 2023 @ 13:44:
[...]


Bedoel je de heat demand van een hr92 knop? Dit is niet echt heat demand maar de klep positie van de hr92.
Die zou overeen moeten komen als je deze opvraagt op de hr92.

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.

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

[slow whoop]

@TheMystery Ik weet niet of dat begrijp. Als sensor.04_xxxxxx_heat_demand van een HR92 eigenlijk de kleppositie is, welke parameter is dan de daadwerkelijke heat demand? Waar haal je die vandaan? Heb je daar een aparte sensor voor aangemaakt? Die kleppositie icoontjes zie ik ook niet terug in mijn entities.

[TheMystery]

slow whoop schreef op donderdag 30 maart 2023 @ 21:25:
@TheMystery Ik weet niet of dat begrijp. Als sensor.04_xxxxxx_heat_demand van een HR92 eigenlijk de kleppositie is, welke parameter is dan de daadwerkelijke heat demand? Waar haal je die vandaan? Heb je daar een aparte sensor voor aangemaakt? Die kleppositie icoontjes zie ik ook niet terug in mijn entities.

Ik heb de hr92 heat demand gerenamed naar kleppositie en icoon aangepast.
Verder moet je standaard per zone nog een extra entiteit krijgen voor heat demand, deze komt overeen met de waardes die je op kunt vragen binnen evohome zelf.
Klopt jou schema van je evohome setup als je de schema entiteit bekijkt?

[slow whoop]

Ok. Dus als ik het goed begrijp zit het zo:

• sensor.04_xxxxxx_heat_demand geeft klep positie van radiatorknop HR92.
• sensor.01_xxxxxx_yy_heat_demand geeft warmtevraag per zone yy.

De warmtevraag per zone zou dus overeen moeten komen met wat ik op m'n Evohome display zie staan.

Wat ik zie in de schema entiteit klopt volgens mij precies met m'n Evohome setup.

[TheMystery]

slow whoop schreef op vrijdag 31 maart 2023 @ 22:12:
Ok. Dus als ik het goed begrijp zit het zo:

• sensor.04_xxxxxx_heat_demand geeft klep positie van radiatorknop HR92.
• sensor.01_xxxxxx_yy_heat_demand geeft warmtevraag per zone yy.

De warmtevraag per zone zou dus overeen moeten komen met wat ik op m'n Evohome display zie staan.

Wat ik zie in de schema entiteit klopt volgens mij precies met m'n Evohome setup.

Klopt helemaal.

[Willems]

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:

[Afbeelding]

Ik zie dat je gekozen hebt voot de ch340g en de andere optie is FTDI, maakt dat nog wat uit? Werkt het verder goed zo?

[vliegnerd]

Willems schreef op vrijdag 18 augustus 2023 @ 11:26:
[...]


Ik zie dat je gekozen hebt voot de ch340g en de andere optie is FTDI, maakt dat nog wat uit? Werkt het verder goed zo?

FTDI wordt beter ondersteund, zeker onder windows. Mijn nanocul gebruikt volgens mij een arduino micro die helemaal geen FTDI of CH340G gebruikt maar waarbij de atmega zelf de USB communicatie regelt. (Denk ik -- nanocul is alweer even geleden)

Ik zou nu geen nanocul meer adviseren maar een SSM-D2: https://indalo-tech.onlineweb.shop/product/ssm-d2
Soms lastig te verkrijgen en je moet importkosten betalen (UK), maar "goedkoop is duurkoop" is mijn ervaring met nanoculs.

Mijn setup werkt pas lekker nadat ik de SSM-D2 ben gaan gebruiken en dan heb ik daarnaast ook nog de antenne vervangen. (Nieuwbouwhuis, SSM-D2 in meterkast en ventilatiesystemen in technische ruimte op tweede verdieping): vliegnerd in "Orcon HRC RF modbus in ESPHome"

[ Voor 0% gewijzigd door vliegnerd op 12-09-2023 11:46 . Reden: spelvauten ]

[Willems]

Thanks! Bedankt voor de tip!

Ik heb ook de warmtepomp op de zolder, en net vanuit de bouwmaatschappij een bridge repeater gekregen in verband met communicatie problemen tussen de thermostaten en de warmtepomp. (Op de bridge trouwens ook nog een RJ45 op, maar ik zie niet hoe ik daarmee zou kunnen werken)

Dus inderdaad goedkoop is duurkoop bedankt voor de tip! Dan ga ik over naar de SSM-D2 :-)

[golfdiesel]

Ik heb een SSM-D2 gekocht en op mijn RPi 4 aangesloten waar ik HA op draai.
Ramses_CC heb ik geïnstalleerd en om te kijken of er iets tevoorschijn komt in de logs heb ik op dit moment alleen de volgende entry in de configuration.yaml gezet.

ramses_cc:
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00

Ik ben nog niet zo heel lang met HA bezig maar in welke logs zouden de packets van ramses_cc zichtbaar moeten worden? Ik niet namelijk nergens wat verschijnen.

[vliegnerd]

golfdiesel schreef op maandag 11 december 2023 @ 17:06:
Ik heb een SSM-D2 gekocht en op mijn RPi 4 aangesloten waar ik HA op draai.
Ramses_CC heb ik geïnstalleerd en om te kijken of er iets tevoorschijn komt in de logs heb ik op dit moment alleen de volgende entry in de configuration.yaml gezet.

ramses_cc:
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00

Ik ben nog niet zo heel lang met HA bezig maar in welke logs zouden de packets van ramses_cc zichtbaar moeten worden? Ik niet namelijk nergens wat verschijnen.

Ik zou eerst kijken of je iets "ontvangt" als je gewoon naar de seriele poort "luistert".

code:

screen /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00 115200

(wel eerst HA afsluiten)

Je ziet dan zoiets:

code:

065  I --- 02:248945 02:250708 --:------ 4E01 018 007FFF7FFF7FFF08527FFF7FFF7FFF7FFF00
045  I --- --:------ --:------ 02:250704 1FD4 003 00E566
045  I --- 02:250704 --:------ 02:250704 3110 004 00002810
063  I --- --:------ --:------ 02:248945 1FD4 003 004030
057  I --- 21:064743 --:------ 21:064743 3EF0 006 020000000200
045  I --- 21:043468 --:------ 21:043468 30C9 003 0007CF

Afhankelijk van het aantal zendende apparaten om je heen moet je best wat van dit soort regels langs zien komen.

Daarnaast kun je in de logfile van home-assistant (home-assistant.log) na het opstarten van HA de "ramses-cc" regels en/of (fout)meldingen zien langskomen.

Als je in je configuration.yaml in het ramses_cc blokje, dit zet:

code:

  packet_log:
    file_name: packet.log

Dan kun je in het "packet.log" bestand bovengenoemde regels zien verschijnen.

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

[marnie]

@vliegnerd

want mijn Orcon doet automatisch helemaal niets.

Ik werd even getriggerd op deze reactie.

Ik heb sinds eind vorig jaar een HRC425 (met zonekleppenregeling) en heb problemen met de dipswitch setup en bijbehorende snelheden. De luchtsnelheden komen, met de CO2 bedieningssensoren gekoppeld aan de kleppen, niet overeen met de dipswitch instelling. Switch 3 op on zou 175m3/3 moeten geven maar is gemeten (met SSM-D2 in Homeassistant) ca 112m3/h. Als ik de bediening op de HRC zelf koppel dan heb ik wel 175m3.
De dipswitch settings om een verschil te maken tussen aan- en afvoer debieten werkt niet, beide fan's volgen de aanvoer setup..

De automatische CO2 regeling werkt pas na 1150ppm, en dan binnen een paar seconden naar een hoog debiet) in het voor mij normale werkgebied van 800-1200ppm.

En nog een paar punten.

Ik heb Orcon er al bij gehad (Groupe Atlantic) zonder resultaat.
Ik vraag me af of meerdere mensen problemen hebben met de Orcon.

[vliegnerd]

marnie schreef op maandag 19 februari 2024 @ 13:35:
@vliegnerd
[...]

Ik werd even getriggerd op deze reactie.

Ik heb sinds eind vorig jaar een HRC425 (met zonekleppenregeling) en heb problemen met de dipswitch setup en bijbehorende snelheden. De luchtsnelheden komen, met de CO2 bedieningssensoren gekoppeld aan de kleppen, niet overeen met de dipswitch instelling. Switch 3 op on zou 175m3/3 moeten geven maar is gemeten (met SSM-D2 in Homeassistant) ca 112m3/h. Als ik de bediening op de HRC zelf koppel dan heb ik wel 175m3.
De dipswitch settings om een verschil te maken tussen aan- en afvoer debieten werkt niet, beide fan's volgen de aanvoer setup..

De automatische CO2 regeling werkt pas na 1150ppm, en dan binnen een paar seconden naar een hoog debiet) in het voor mij normale werkgebied van 800-1200ppm.

En nog een paar punten.

Ik heb Orcon er al bij gehad (Groupe Atlantic) zonder resultaat.
Ik vraag me af of meerdere mensen problemen hebben met de Orcon.

Ik herken jouw problemen niet. Maar....

Hier werkt de CO2 regeling wel. Maar de vochtigheidsregeling helemaal niet. Er gebeurt echt helemaal niets. En ik kan het zien omdat ik de boel uitlees met ramses_cc/HA/SSM-D2. Maar ook met een simpele smartplug op de stekker kun je zien dat de Orcon HRC 425 (ingesteld op max 300 m3/h) echt helemaal niets doet als de vochtheidheid snel stijgt.
De sensor doet het wel prima. Gelukkig maar, want daarop stuur ik nu via HA.

Ook werkt de timer stand 2 niet via de RF15 CO2. Dan moet dat ding 12 of 13 uur in stand 2 gaan. Is bedoeld als nachtstand, als je geen CO2 sturing hebt. Of geen CO2 meters in alle kamers. De Orcon HRC gaat wel naar stand 2 maar het debiet blijft laag zoals in stand 1.
Als ik met een non-CO2 remote stand 2 selecteert (dus gewoon stand 2 zonder timer) dan werkt stand 2 wel prima.
Ik weet niet meer precies of ik al getest had of het aan de zone-klepunit ligt. Want die zitten tussen de HRC en de RF15 CO2. En die zone klep unit stuurt dit soort berichten "Ga naar stand 2 timer ..." door naar de HRC. Maar volgens mij ligt het daar niet aan.

Probleem is: Installateur kan en wil niks. Die zeggen vrijwel letterlijk: "Het groene lampje brand dus het werkt". "Het is ingeregeld, het werkt automatisch, vertrouw het systeem". Dat het ingeregeld is, is waarschijnlijk een leugen. Mijn buurman probeert al 2+ jaar het inregelrapport te bemachtigen. Bij mij zaten de slaapkamer ventielen helemaal dicht. (Dat kan na inregelen gebeurt zijn door weer een andere bouwvakbeun...)

Bij andere buren is Orcon langsgeweest. Die weten natuurlijk dat de boel kapot is/niet werkt maar die doen of hun neus bloedt. Of wellicht zijn ze ook incompetent. Die buren kregen het advies om handmatig stand 3 te kiezen voor het douchen. Doe ik al 2 jaar, maar niet echt een oplossing voor een automatisch systeem dat niet werkt.

In de praktijk kan ik dus niet veel met mijn duidelijk defecte Orcon. (Wellicht een hele serie waarbij er een hard- of software bug in de vochtigheidssturing zit, of een instelling die alleen voor Orcon bereikbaar is...)

[ Voor 3% gewijzigd door vliegnerd op 19-02-2024 13:47 ]

[Vaevictis_]

vliegnerd schreef op maandag 19 februari 2024 @ 13:45:
[...]


Ik herken jouw problemen niet. Maar....

Hier werkt de CO2 regeling wel. Maar de vochtigheidsregeling helemaal niet. Er gebeurt echt helemaal niets. En ik kan het zien omdat ik de boel uitlees met ramses_cc/HA/SSM-D2. Maar ook met een simpele smartplug op de stekker kun je zien dat de Orcon HRC 425 (ingesteld op max 300 m3/h) echt helemaal niets doet als de vochtheidheid snel stijgt.
De sensor doet het wel prima. Gelukkig maar, want daarop stuur ik nu via HA.

Ook werkt de timer stand 2 niet via de RF15 CO2. Dan moet dat ding 12 of 13 uur in stand 2 gaan. Is bedoeld als nachtstand, als je geen CO2 sturing hebt. Of geen CO2 meters in alle kamers. De Orcon HRC gaat wel naar stand 2 maar het debiet blijft laag zoals in stand 1.
Als ik met een non-CO2 remote stand 2 selecteert (dus gewoon stand 2 zonder timer) dan werkt stand 2 wel prima.
Ik weet niet meer precies of ik al getest had of het aan de zone-klepunit ligt. Want die zitten tussen de HRC en de RF15 CO2. En die zone klep unit stuurt dit soort berichten "Ga naar stand 2 timer ..." door naar de HRC. Maar volgens mij ligt het daar niet aan.

Probleem is: Installateur kan en wil niks. Die zeggen vrijwel letterlijk: "Het groene lampje brand dus het werkt". "Het is ingeregeld, het werkt automatisch, vertrouw het systeem". Dat het ingeregeld is, is waarschijnlijk een leugen. Mijn buurman probeert al 2+ jaar het inregelrapport te bemachtigen. Bij mij zaten de slaapkamer ventielen helemaal dicht. (Dat kan na inregelen gebeurt zijn door weer een andere bouwvakbeun...)

Bij andere buren is Orcon langsgeweest. Die weten natuurlijk dat de boel kapot is/niet werkt maar die doen of hun neus bloedt. Of wellicht zijn ze ook incompetent. Die buren kregen het advies om handmatig stand 3 te kiezen voor het douchen. Doe ik al 2 jaar, maar niet echt een oplossing voor een automatisch systeem dat niet werkt.

In de praktijk kan ik dus niet veel met mijn duidelijk defecte Orcon. (Wellicht een hele serie waarbij er een hard- of software bug in de vochtigheidssturing zit, of een instelling die alleen voor Orcon bereikbaar is...)

Ik heb 2 jaar geleden van Orcon een nieuwe print ontvangen voor de HRC400 met een nieuwe vochtsensor deze is supergevoelig en werkt als een dolle. Binnen 1 min. douchen gaat de WTW optoeren. Voorheen deed deze ook niets en moest ik met een programmeerbare hulp ventilator werken (Vent axia Swara) om de WTW aan te jagen. Deze ventilator ligt nu werkeloos in de kast (DM maar bij interesse).

Ik denk dat het een combinatie is van nieuwe software en betere sensor. @vliegnerd @marnie

[marnie]

@vliegnerd ik heb je een dm gestuurd.
Hier werkt de vochtigheidsregeling prima. Het wordt getriggerd door de douche in de badkamer en zelfs door het beetje stoom van de Quooker in de keuken.

Stand 2 van de CO2 bediening werkt hier ook goed en is ook uit te lezen in HA. Omdat de CO2 regeling veel te laat wordt aangesproken gebruik ik een automatisering in HA die vanaf 800ppm CO2 de HRC in stand 2 zet, hierdoor blijft het CO2 gehalte in de slaapkamer onder de 1100ppm, vaak rond de 1000ppm. De kleppen doen in stand 2 ook een beetje hun werk, volgens Orcon.

Ik heb nog een tijdje getest met een automatisering waarin afhankelijk van de CO2 waarde het debiet werd aangepast (bv 800-850ppm +10%, 850-900ppm +20%) echter dan doen de kleppen, niet mee.

Wel heel vreemd, hetzelfde type WTW maar verschillen in de werking. Mijn gedachte: het kan een inregel probleem zijn maar ook een verschil in de software van de WTW

[jweetje]

Dankzij dit topic ben ik ook gaan pielen om mijn ORCON hrc-400 via HA aan te sturen. Ik heb de stick van indalo-tech en zie wat berichten in de packet.log. Echter heb ik niet helder hoe ik nu kan bepalen welke ID bij welk device type hoort zodat ik e.a. verder in HA kan inrichten. Op de GitHub wiki kom ik niet veel verder. Heeft iemand een handige tip of tutorial misschien?

[GeeMoney]

jweetje schreef op maandag 4 maart 2024 @ 20:49:
Dankzij dit topic ben ik ook gaan pielen om mijn ORCON hrc-400 via HA aan te sturen. Ik heb de stick van indalo-tech en zie wat berichten in de packet.log. Echter heb ik niet helder hoe ik nu kan bepalen welke ID bij welk device type hoort zodat ik e.a. verder in HA kan inrichten. Op de GitHub wiki kom ik niet veel verder. Heeft iemand een handige tip of tutorial misschien?

Het is vooral even goed op letten en veel aan je settings wijzigen, dan zie je vanzelf het ID wat op dat moment dus vaak voorbij komt. Dat is 95% zeker de juiste.

[_JGC_]

jweetje schreef op maandag 4 maart 2024 @ 20:49:
Dankzij dit topic ben ik ook gaan pielen om mijn ORCON hrc-400 via HA aan te sturen. Ik heb de stick van indalo-tech en zie wat berichten in de packet.log. Echter heb ik niet helder hoe ik nu kan bepalen welke ID bij welk device type hoort zodat ik e.a. verder in HA kan inrichten. Op de GitHub wiki kom ik niet veel verder. Heeft iemand een handige tip of tutorial misschien?

Je box stuurt na elke druk op de knop van de afstandsbediening een bevestiging, dus die kan je redelijk snel vinden. Eventueel kan je de box openmaken en zoeken naar een sticker met getallen, die moet je dan naar hexadecimaal omzetten (3 groepjes van 2 decimale getallen).

[vliegnerd]

jweetje schreef op maandag 4 maart 2024 @ 20:49:
Dankzij dit topic ben ik ook gaan pielen om mijn ORCON hrc-400 via HA aan te sturen. Ik heb de stick van indalo-tech en zie wat berichten in de packet.log. Echter heb ik niet helder hoe ik nu kan bepalen welke ID bij welk device type hoort zodat ik e.a. verder in HA kan inrichten. Op de GitHub wiki kom ik niet veel verder. Heeft iemand een handige tip of tutorial misschien?

Het kan een puzzeltje zijn, zeker omdat je vaak ook berichten van apparatuur van de buren kan ontvangen.

Schakel met een remote van auto naar stand 3. Je ziet dan berichten met 22F3 (tijdelijke boost) en/of 22F1 (ventilatie stand)

In mijn geval, vanmorgen toen de eerste huisgenoot ging douchen:

code:

2024-03-05T06:33:49.864227 065  I --- 37:005608 32:132403 --:------ 22F3 007 00123C03040404
2024-03-05T06:33:49.885234 063  I --- 32:132403 32:134446 --:------ 22F3 007 00123C03040404

De CO2 remote 37:005608 stuurt een 22F3 bericht "ga naar stand 3 voor 60 minten" aan de klepunit 32:132403. Dat is de eerste regel
De tweede regel is de klepunit die het bericht doorstuurt aan de HRC425 fanunit.

37:005608 stuurt ook 1298 (co2) en 31E0 (ventdemand). Dit is duidelijk een CO2 remote
32:132403 en afstandsbedieningen sturen 31D9 heen-en-weer. Dit is de klepunit.
32:134446 stuurt als enige 31DA berichten (lange berichten) met alle informatie van de fan snelheden en temperaturen. Dit is dus de fan.

Je mag hier ook een stukje packet.log plakken, dan puzzelen we met je met.
(gebruik pastebin.com, geef de duidelijk de tijd aan waar je wisselt tussen fan standen en stuur ook een uurtje log mee)

[Onl1ne1373]

Je kan ook de client.py tool van ramses_rf gebruiken om je packet.log te parsen en te converteren naar leesbare berichten.

code:

cat packet.log | python3 client.py parse

Ik haal meestal de packet.log naar mijn linux vm en draai daar de tool.

[jweetje]

Dank voor de input! Hier kan ik wel wat verder mee puzzelen. Indien ik er niet uit kom drop ik hier een stukje log. Thanks

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

[rfcdejong]

Zo'n dongle is nergens meer te koop, alleen die nanocell wel

Of zou deze ook werken voor evofw3 met ramses?

Rfx868

[rfcdejong]

De site van indalo tech is weer online. Ik zie daar een "ESP32-S3 + 868MHz CC1101 USB stick" comming soon. Is dat de vervanger van SSM-D2 ? Ramses ESP

[vliegnerd]

rfcdejong schreef op vrijdag 31 mei 2024 @ 08:38:
De site van indalo tech is weer online. Ik zie daar een "ESP32-S3 + 868MHz CC1101 USB stick" comming soon. Is dat de vervanger van SSM-D2 ? Ramses ESP

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

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

[neographikal]

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]

neographikal 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

[neographikal]

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]

neographikal 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

[neographikal]

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

[neographikal]

XElD schreef op maandag 7 april 2025 @ 11:47:
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.

De HA-integratie is wat minder boeiend, zolang het ESP-deel maar blijft werken tegen MQTT aan. De rest valt te fixen. Als het niet linksom kan, dan maar rechtsom: https://github.com/sandervandegeijn/OrconRamsesRFCommand

[ Voor 8% gewijzigd door neographikal op 28-04-2025 20:23 ]