[OTGW] OpenTherm gateway

[Matis]

remcoXP schreef op maandag 25 april 2016 @ 17:54:
als ik hem aansluit hij is connected en ik open de website krijg ik in de logging van windows openterm monitor:

code:

17:52:42.489768 Opentherm ÿ
17:52:42.498713 Command (via relay server, from 192.168.0.8:52788): PS=1
17:53:12.419044 Command (via relay server, from 192.168.0.8:52788): SC=17:53/1
17:53:12.479269 Command (via relay server, from 192.168.0.8:52788): PR=G
17:53:12.484812 
17:53:12.496333 Command (via relay server, from 192.168.0.8:52788): PR=I
17:53:12.732239 Command (via relay server, from 192.168.0.8:52788): PR=O
17:53:12.737501 Command (via relay server, from 192.168.0.8:52788): PS=1
17:53:12.745942 
17:53:42.424115 Command (via relay server, from 192.168.0.8:52788): SC=17:53/1
17:53:42.429872 
17:53:42.447321 Command (via relay server, from 192.168.0.8:52788): PR=G
17:53:42.452383 Command (via relay server, from 192.168.0.8:52788): PR=I
17:53:42.462570 Command (via relay server, from 192.168.0.8:52788): PR=O
17:53:42.472637 Openô
17:53:42.482648 Command (via relay server, from 192.168.0.8:52788): PS=1

het valt me op dat ik rare tekens zie.

in diagnostics zie ik:
Openthermà

en als ik firmware (gateway of normaal wil updaten krijg ik altijd failed:

code:

error reading "file3ff8368": I/O error
error reading "file3ff8368": I/O error
    while executing
"read $fd"
    (procedure "::diag::receive" line 6)
    invoked from within
"::diag::receive file3ff8368"

heb ik hem bricked? of weer een defect exemplaar?

Die gekke y is 255 decimaal. Ik denk dat Windows encoding roet in het eten gooit.
Kun jij je terminal in UTF8 forceren?

[remcoXP]

ik heb led rca connectoren (superidee) enz ook besteld maar als mijn tweede gateway het standaard al niet doet heeft het weinig zin. is er hier iemand op het forum die tegen een kleine vergoeding mij kan helpen? ik kom er niet uit.
En het lijkt me beter dan de arduino om mijn aanvoer en retour te monitoren

[CyBeRSPiN]

Hm, ik krijg het niet aan de praat.
Mn thermostaat (Celcia 20) geeft 'OT ERROR' (dat doet ie ook als ie helemaal niet aangesloten is).
In diagnostic test geeft de boiler bij 'voltage levels' 0.0 aan.
Als ik X1 en X2 meet wanneer ze doorgelust zijn, dan zijn beide 17V.
Als ik voltage meet als thermostaat en ketel aangesloten zijn dan is X1 (thermostaat) 4,7V en X2 (boiler) 6,2V
Is dat normaal? Of is voltage richting thermostaat te laag?

Geen idee hoe ik dit verder moet debuggen, heb troubleshooting op OTGW website al nagelopen.

update
Werkt inmiddels. Had stukje UTP kabel gebruikt om thermostaat/boiler aan te sluiten. Blijkbaar werkte dat niet.
Met ander kabeltje aangesloten en zowel thermostaat als boiler geven input..
Jeej

[ Voor 16% gewijzigd door CyBeRSPiN op 25-04-2016 23:07 ]

[balk]

[quote]gibraltar schreef op maandag 25 april 2016 @ 13:36:
[...]

Ik heb een iSense (volgens mij v21) en die werkt prima met de "TT" en "TC" commando's. Overigens kan het even duren voordat je ID 100 voorbij ziet komen. De OTGW heeft ook een ingebouwde counter die hij gebruikt om "invalid" ID's te filteren. Je kan die resetten met "KI=9" en "KI=100". Eventueel kan de detectie van thermostaat type een beetje in de soep lopen, dan kun je "FT=I" (met de I van iSense) gebruiken om de OTGW te overtuigen dat het een iSense is.
[/quote]
hmmm, dit alles heeft nog niet geholpen.

Wat heb ik gedaan?
[list]
[li]Ik heb de firmware opnieuw geflasht omdat ik van een iSense v19 naar v23 gegaan ben[/li]
[li]ik heb een half uur gewacht[/]
[li]ik heb KI=9 en KI=100 gedaan[/]
[/list]
Iemand met een v23 waarbij het wel werkt? Kan dit iets hardwarematig zijn in de OTGW?

Het lijkt te werken! Na het veranderen van deze instelling op de thermostaat (iSense v23) kan ik TT=xx doorgeven en verandert de ingestelde temperatuur op de thermostaat ook daadwerkelijk:
Instellingen --> Installateur --> Externe Ingang --> Toestaan
ik zie nu in ieder geval ID 9 en 100 in de lijst staan.

[ Voor 16% gewijzigd door balk op 28-04-2016 06:23 . Reden: het werkt! ]

[CyBeRSPiN]

Nu nog issue om het te laten werken met de USR-TCP232-T..

De LAN module werkt, de OTGW werkt als ik rechtstreeks via USB TTL aansluit.
Maar als ik de OTGW wil bereiken via de USR dan lukt het niet.

USR staat in TCP server mode, alle 'special functions' staan uit (o.a. RS485, RFC2217).
Alleen als ik 9600 baud, parity None, data 7 en stopbit 1 kies, dan krijg ik wat output (rommel) als ik commando 'PR=B' stuur.
TX en RX pinnen ook al meerdere keren gewisseld.

Wat doe ik fout?

----

Schiet mij maar lek.. Uren zitten vogelen.. En nu werkt het ineens (databits=8), had deze combi al meerdere keren geprobeerd, geen idee waarom het nu ineens werkt..

[ Voor 20% gewijzigd door CyBeRSPiN op 27-04-2016 17:15 ]

[rippiedoos]

CyBeRSPiN schreef op woensdag 27 april 2016 @ 17:07:
Nu nog issue om het te laten werken met de USR-TCP232-T..

De LAN module werkt, de OTGW werkt als ik rechtstreeks via USB TTL aansluit.
Maar als ik de OTGW wil bereiken via de USR dan lukt het niet.

USR staat in TCP server mode, alle 'special functions' staan uit (o.a. RS485, RFC2217).
Alleen als ik 9600 baud, parity None, data 7 en stopbit 1 kies, dan krijg ik wat output (rommel) als ik commando 'PR=B' stuur.
TX en RX pinnen ook al meerdere keren gewisseld.

Wat doe ik fout?

----

Schiet mij maar lek.. Uren zitten vogelen.. En nu werkt het ineens (databits=8), had deze combi al meerdere keren geprobeerd, geen idee waarom het nu ineens werkt..

Ik kan mij ook zoiets herinneren. Die USR moet van sommige dingen meerdere keren overtuigd worden. Bij mij was het het ip-adres volgens mij. Moest ik 3x instellen en daarna werkte het pas volgens mij. Maar als het eenmaal werkt dan werkt het ook echt als een speer. En stabiel zover ik kan bepalen!

[CyBeRSPiN]

Eerste bezuiniging is nu meteen al een feit!
Bleek dat de ketel in 'comfort stand' stond, dus steeds kort gas gebruiken om het warm water op 60 graden te houden.. 24/7/365... Zag het meteen in de grafiek gebeuren.
We hebben eigenlijk alleen 's ochtends warm water nodig van de CV (hebben boiler voor keuken beneden) en daar wachten we dan maar een tel langer op, beetje jammer dat ie zo al jaren heeft gewerkt..

Misschien idee voor anderen die ook LAN interface willen gebruiken.
Je zou met een soort van PoE kunnen werken, dus voeden d.m.v. de (ongebruikte) UTP aders. Dan ben je veel flexibeler in de plaatsing van de gateway.
http://www.ebay.com/itm/141651355231 -> PoE splitters.
Vervolgens een 24V voeding nemen en dan voor een uitvoering gaan zonder de print-trafo maar met een DC/DC converter (om van de 24V 5V te maken), zoals deze:maxnl in "[OTGW] OpenTherm gateway"

Kom er nu wel achter dat ik de RESET button nog moet toevoegen. Voor firmware flashen via de LAN module moet je de gateway zelf resetten. Powercyclen werkt niet omdat dan ook de LAN module down gaat.

[balk]

ThinkPadd schreef op maandag 18 januari 2016 @ 14:18:
[...]

Geen idee, misschien Domoticz afsluiten en dan met cu / minicom o.i.d.

Ik heb de OTGW niet in Domoticz hangen, ik heb in een losse VM de otmonitor draaien die de OTGW uitleest (via een Serial to Ethernet module, OTGW is dus niet fysiek met de VM verbonden). In een andere VM draait de Java-applicatie 'tendens' geschreven door medetweaker 'nickyb2'. Op die manier kan ik alle data mooi plotten.

Het voordeel van otmonitor is dat je gewoon via webbrowser de commando's kan sturen. Ik kan via een simpele GET-request bijv. de gewenste kamertemperatuur overriden. (http://ip/.....?command=TT=19 geloof ik).

Ik zit nu al een tijdje te klooien met tendens maar ik krijg het niet aan de praat. Wat heb ik gedaan?

• Tomcat 8 geïnstalleerd op mij Raspbian Jessie
• Tomcat laten praten met poort 8070 omdat Domoticz al op 8080 zit
• tendens gedownload, mib2011-tendens-0af232a29b78.zip

Vervolgens

1. deze zip hernoemd naar tendens.war en via de tomcat manager ingeladen, werkt niet
2. zip uitgepakt in /var/lib/tomcat8/webapps/tendens
3. war in /var/lib/tomcat8/webapps/ geplaatst

In al deze gevallen gaf http://192.168.0.10:8070/tendens/ de volgende foutmelding

code:

type Status report

message /tendens/

description The requested resource is not available.

Kan iemand mij op weg helpen?

[Matis]

Ik heb ooit een script geschreven om Tendens binnen Turnkey Tomcat te installeren en configureren. Misschien heb je er wat aan: https://gist.github.com/toaomatis/4cb4f367e41721fffa23

[ThinkPad]

balk schreef op donderdag 28 april 2016 @ 22:04:
[...]
Kan iemand mij op weg helpen?

Het .zip bestand wat je daar hebt is alleen de source geloof ik, ik gebruikte altijd een gecompileerde .war die ik vervolgens moest hernoemen naar ROOT.war en dan droppen ergens in een map van Tomcat.

Die gecompileerde .war is niet meer aanwezig op BitBucket dus je kunt beter naar iets als InfluxDB + Grafana kijken, daarmee kun je hetzelfde (en meer) als met tendens.

[ Voor 7% gewijzigd door ThinkPad op 29-04-2016 14:49 ]

[balk]

ThinkPadd schreef op vrijdag 29 april 2016 @ 14:38:
[...]

Het .zip bestand wat je daar hebt is alleen de source geloof ik, ik gebruikte altijd een gecompileerde .war die ik vervolgens moest hernoemen naar ROOT.war en dan droppen ergens in een map van Tomcat.

Die gecompileerde .war is niet meer aanwezig op BitBucket dus je kunt beter naar iets als InfluxDB + Grafana kijken, daarmee kun je hetzelfde (en meer) als met tendens.

Aha vandaar Ik probeerde al zelf een war te maken mbv Maven maar dat werkte ook niet. Thanks voor je reactie en tip!

[Verwijderd]

balk schreef op vrijdag 29 april 2016 @ 18:50:
[...]

Aha vandaar Ik probeerde al zelf een war te maken mbv Maven maar dat werkte ook niet. Thanks voor je reactie en tip!

Het zelf bouwen zou dan wel weer moeten werken .

Ik zelf ben ook overgestapt op InfluxDB en Grafana, kan alles wat ik met tendens ook kon. Dus ik zie zelf geen reden om daar nog mee verder te gaan. Had ik eerder van Grafana geweten was ik zelf nooit aan tendens begonnen. De eenvoud waarmee ik hetzelfde voor elkaar krijg met Grafana als met tendens zal er denk ik voor gaan zorgen dat de tendens repo wel offline gaat. Maar dan zal ThinkPad eerst gaan eisen dat ik in een tweakblog in elkaar knutsel hoe ik het onderstaande voor elkaar krijg:

[ Voor 16% gewijzigd door Verwijderd op 29-04-2016 18:58 ]

[balk]

Verwijderd schreef op vrijdag 29 april 2016 @ 18:56:
[...]


Het zelf bouwen zou dan wel weer moeten werken .

Ik zelf ben ook overgestapt op InfluxDB en Grafana, kan alles wat ik met tendens ook kon. Dus ik zie zelf geen reden om daar nog mee verder te gaan. Had ik eerder van Grafana geweten was ik zelf nooit aan tendens begonnen. De eenvoud waarmee ik hetzelfde voor elkaar krijg met Grafana als met tendens zal er denk ik voor gaan zorgen dat de tendens repo wel offline gaat. Maar dan zal ThinkPad eerst gaan eisen dat ik in een tweakblog in elkaar knutsel hoe ik het onderstaande voor elkaar krijg:

[afbeelding]

hmm, dat ziet er wel vet uit. Helaas loopt dit ook hier nog niet. Het lijkt alsof domoticz de data niet naar infludb stuurt.

Ik heb, naast de URL in onderstaande screenshot ook deze geprobeerd: http://localhost:8086/write?db=domoticz


Het vinkje om te loggen staat aan, maar in de log komt ook niks voorbij. Deze amateuristische net-niet-nerd voet zich een beetje kikker...

[Verwijderd]

balk schreef op vrijdag 29 april 2016 @ 22:07:
[...]

hmm, dat ziet er wel vet uit. Helaas loopt dit ook hier nog niet. Het lijkt alsof domoticz de data niet naar infludb stuurt.

Ik heb, naast de URL in onderstaande screenshot ook deze geprobeerd: http://localhost:8086/write?db=domoticz
[afbeelding]

Het vinkje om te loggen staat aan, maar in de log komt ook niks voorbij. Deze amateuristische net-niet-nerd voel me een beetje kikker...

Ik gebruik zelf geen Domoticz, maar lees de OTGW uit doormiddel van het uitlezen van de otmonitor. Naar mijn weten zet Domoticz de OTGW in de verkeerde modus of zoiets om hem goed uit te lezen. Ik kan het mis hebben hoor.

In grote lijnen heb ik een InfluxDB en Grafana draaien op een VM. Mijn OTGW zit op zolder vast aan een Raspberry PI welke 24/7 de otmonitor draait. Door middel van een script dat ik geschreven heb in python trekt hij elke 15 seconden en elke modus wijziging (warm water aan/uit, cv aan/uit, etc) de laatste data uit de otmonitor en stopt hij dan in InfluxDB. Vervolgens is het een Dashboard maken in Grafana en klaar is kees.

Er zit nog wat extra dingetjes om heen, monit om de boel draaiend te houden. Mijn PI zit met Wifi vast aan het netwerk en is eigenlijk net buiten bereik dus wil nog wel eens uitvallen. Ik gebruik Supervisor voor het starten van de otmonitor en nog wat boilerplate.

Ik zal er binnenkort eens voor gaan zitten om het allemaal op te typen.

[balk]

Verwijderd schreef op vrijdag 29 april 2016 @ 22:22:
[...]


Ik gebruik zelf geen Domoticz, maar lees de OTGW uit doormiddel van het uitlezen van de otmonitor. Naar mijn weten zet Domoticz de OTGW in de verkeerde modus of zoiets om hem goed uit te lezen. Ik kan het mis hebben hoor.

In grote lijnen heb ik een InfluxDB en Grafana draaien op een VM. Mijn OTGW zit op zolder vast aan een Raspberry PI welke 24/7 de otmonitor draait. Door middel van een script dat ik geschreven heb in python trekt hij elke 15 seconden en elke modus wijziging (warm water aan/uit, cv aan/uit, etc) de laatste data uit de otmonitor en stopt hij dan in InfluxDB. Vervolgens is het een Dashboard maken in Grafana en klaar is kees.

Er zit nog wat extra dingetjes om heen, monit om de boel draaiend te houden. Mijn PI zit met Wifi vast aan het netwerk en is eigenlijk net buiten bereik dus wil nog wel eens uitvallen. Ik gebruik Supervisor voor het starten van de otmonitor en nog wat boilerplate.


Ik zal er binnenkort eens voor gaan zitten om het allemaal op te typen.

Mijn issue is eigenlijk ook meer een Domoticz issue dan een OTGW issue en hoort dus niet in deze thread thuis... OTGW praat via wifi/telnet met Domoticz op een Pi in de meterkast en dat gaat goed. De P1 poort wordt ook uitgelezen. Ik ga het morgen weer proberen, en anders stel ik de vraag in het Domoticz topic

[edit]
Opgelost dankzij DJFliX

[ Voor 3% gewijzigd door balk op 02-05-2016 21:35 ]

[iMars]

balk schreef op vrijdag 29 april 2016 @ 22:40:
[...]

Mijn issue is eigenlijk ook meer een Domoticz issue dan een OTGW issue en hoort dus niet in deze thread thuis... OTGW praat via wifi/telnet met Domoticz op een Pi in de meterkast en dat gaat goed. De P1 poort wordt ook uitgelezen. Ik ga het morgen weer proberen, en anders stel ik de vraag in het Domoticz topic

Ik ervaar hetzelfde hier. Ik heb otmonitor op mijn Rpi (met domoticz) draaien, en relaying open gezet. Vervolgens maakt domoticz connectie naar otmonitor, en het vanaf het moment dat domoticz het signaal oppakt, stopt otmonitor met loggen... super irritant.

[timoline]

Verwijderd schreef op vrijdag 29 april 2016 @ 18:56:
[...]


Het zelf bouwen zou dan wel weer moeten werken .

Ik zelf ben ook overgestapt op InfluxDB en Grafana, kan alles wat ik met tendens ook kon. Dus ik zie zelf geen reden om daar nog mee verder te gaan. Had ik eerder van Grafana geweten was ik zelf nooit aan tendens begonnen. De eenvoud waarmee ik hetzelfde voor elkaar krijg met Grafana als met tendens zal er denk ik voor gaan zorgen dat de tendens repo wel offline gaat. Maar dan zal ThinkPad eerst gaan eisen dat ik in een tweakblog in elkaar knutsel hoe ik het onderstaande voor elkaar krijg:

[afbeelding]

Dat ziet er goed uit! Ben ook wel heel erg benieuwd hoe je dat heb gedaan :-)

[gibraltar]

iMars schreef op vrijdag 29 april 2016 @ 23:54:
[...]
Ik ervaar hetzelfde hier. Ik heb otmonitor op mijn Rpi (met domoticz) draaien, en relaying open gezet. Vervolgens maakt domoticz connectie naar otmonitor, en het vanaf het moment dat domoticz het signaal oppakt, stopt otmonitor met loggen... super irritant.

De exact reden hiervoor is dat Domoticz in plaats van push (real-time) een pull methode gebruikt. De plugin vraagt hierin zelf een samenvatting op. De otmonitor gebruikt echter het parsen van de data zodra deze binnenkomt. Dit staat hier:

Print Summary - The opentherm gateway normally prints every opentherm message it receives, as well as the modified messages it transmits. In some applications it may be more useful to only get a report of the latest values received for the most interesting parameters on demand. Issuing a "PS=1" command will stop the reports for each message and print one line with the following values:

Ik opperde laatst al de oplossing: een stukje software ertussen die het "PS=1" commando emuleert, en de seriële communicatie voor de rest met rust laat.

[ThinkPad]

Eigenlijk is de Domoticz oplossing in die zin best wel brak, het zou veel netter zijn als hij gewoon luistert naar wat er voorbij komt op de socket. Maarja ik kan het wel begrijpen, deze oplossing was veel eenvoudiger te implementeren.

[Verwijderd]

Na dagen lange druk van ThinkPad (geintje) heb ik de oplossing opgeschreven in mijn TweakBlog.

Met een dosis IT kennis moeten jullie er wel uit kunnen komen denk ik. Het is niet zo heel moeilijk, maar het resultaat mag er wezen. Uiteraard werkt dit niet als Domoticz de PS=1 zet, maar dat wordt in de blog post wel duidelijk.

Ik hoor graag verbeteringen, bugs en andere kritiek zodat we het nog beter kunnen maken

ThinkPad heeft het net getest en heeft nu dezelfde oplossing draaien en zit nu gefrustreerd te wachten totdat er meer data beschikbaar is en ik voel de druk al om mijn P1/Slimmemeter oplossing ook te delen maar daar ben ik zelf nog niet mee klaar.

[Osiris]

Grafana staat alleen niet in de officiële repo's zie ik en het wil een heeeeeeeeeeeeleboel "vage" dependencies installeren..

Ziet er enorm gaaf uit hoor, maar om nou 10+ apps van mogelijk dubieuze afkomst te installeren op m'n server

[Verwijderd]

Osiris schreef op zaterdag 30 april 2016 @ 15:27:
Grafana staat alleen niet in de officiële repo's zie ik en het wil een heeeeeeeeeeeeleboel "vage" dependencies installeren..

Ziet er enorm gaaf uit hoor, maar om nou 10+ apps van mogelijk dubieuze afkomst te installeren op m'n server

Nu ben ik nog niet zo heel thuis in Ubuntu als in andere OSen, maar als ik Grafana installeer via hun APT repository dan krijg ik de volgende drie dependencies mee:

fontconfig-config
fonts-dejavu-core
libfontconfig1

en naar mijn weten komen deze drie uit de officiële Ubuntu repositories. Dus welke vage dependencies van mogelijk dubieuze afkomst bedoel je dan precies?

[Osiris]

Verwijderd schreef op zaterdag 30 april 2016 @ 15:59:
[...]


Nu ben ik nog niet zo heel thuis in Ubuntu als in andere OSen, maar als ik Grafana installeer via hun APT repository dan krijg ik de volgende drie dependencies mee:

fontconfig-config
fonts-dejavu-core
libfontconfig1

en naar mijn weten komen deze drie uit de officiële Ubuntu repositories. Dus welke vage dependencies van mogelijk dubieuze afkomst bedoel je dan precies?

Deze

Blijkbaar worden die door Go automagisch geïnstalleerd ofzo? Maar ze worden door de onofficiële Gentoo ebuild als 'externe' dependency gebruikt.

[ Voor 14% gewijzigd door Osiris op 30-04-2016 16:54 ]

[Verwijderd]

Osiris schreef op zaterdag 30 april 2016 @ 16:37:
[...]

Deze

Blijkbaar worden die door Go automagisch geïnstalleerd ofzo? Maar ze worden door de onofficiële Gentoo ebuild als 'externe' dependency gebruikt.

Go is de taal waarin zowel InfluxDB als Grafana is in geschreven, dacht ik. Ik gok dat ik ze mee krijg in de Ubuntu build of Ubuntu moet het al bevatten want ik zie ze niet geïnstalleerd worden als extra dependency. Aan mijn kant ziet het er dan heel wat minder spannend uit dan bij jou.

[maxnl]

ThinkPadd schreef op zaterdag 30 april 2016 @ 12:49:
Eigenlijk is de Domoticz oplossing in die zin best wel brak, het zou veel netter zijn als hij gewoon luistert naar wat er voorbij komt op de socket. Maarja ik kan het wel begrijpen, deze oplossing was veel eenvoudiger te implementeren.

Vind het persoonlijk juist wel netter om alleen gegevens (periodiek) op te vragen als je ze daadwerkelijk nodig hebt.
I.p.v. 24 uur per dag elke seconde meerdere opentherm berichten over wifi/netwerk te knallen of er nu wel of niet wat mee gedaan wordt, en of de verstuurde waarde nu gewijzigd is sinds het vorige bericht of niet.

[ Voor 5% gewijzigd door maxnl op 30-04-2016 19:43 ]

[UltraSub]

Periodiek opvragen is normaal. Maar als je real time data samples wil als je dat request doet ontkom je er niet aan die data realtime ergens in te stoppen. Of je dat nou op OTGW doet, of op Domoticz, of in een database als Influx of Elastic, ergens zal die data moeten staan.

[Osiris]

Verwijderd schreef op zaterdag 30 april 2016 @ 18:14:
[...]


Go is de taal waarin zowel InfluxDB als Grafana is in geschreven, dacht ik. Ik gok dat ik ze mee krijg in de Ubuntu build of Ubuntu moet het al bevatten want ik zie ze niet geïnstalleerd worden als extra dependency. Aan mijn kant ziet het er dan heel wat minder spannend uit dan bij jou.

Het lijkt wel alsof al die Go-meuk alleen nodig is om 't e.e.a. qua binaries in elkaar te flansen. Zojuist in VirtualBox een compleet kale Ubuntu aangemaakt en eigenlijk alléén Grafana geïnstalleerd en ondanks dat staat er géén Go op die server

[Verwijderd]

Osiris schreef op zondag 01 mei 2016 @ 00:07:
[...]

Het lijkt wel alsof al die Go-meuk alleen nodig is om 't e.e.a. qua binaries in elkaar te flansen. Zojuist in VirtualBox een compleet kale Ubuntu aangemaakt en eigenlijk alléén Grafana geïnstalleerd en ondanks dat staat er géén Go op die server

Zou het kunnen zijn dat de Go op Gentoo nodig omdat er daar Grafana gecompileerd gaat worden? Ubuntu zal vast de binaries plaatsen, zodoende dus geen Go zelf.

Bij mij zit Grafana ook in zijn eigen VM, samen met InfluxDB dan. Ook enkel alleen dat geinstaleerd.

[Verwijderd]

maxnl schreef op zaterdag 30 april 2016 @ 19:34:
[...]


Vind het persoonlijk juist wel netter om alleen gegevens (periodiek) op te vragen als je ze daadwerkelijk nodig hebt.
I.p.v. 24 uur per dag elke seconde meerdere opentherm berichten over wifi/netwerk te knallen of er nu wel of niet wat mee gedaan wordt, en of de verstuurde waarde nu gewijzigd is sinds het vorige bericht of niet.

Dat ligt aan je doel met de gegevens. Als je bijvoorbeeld je CV ketel in wilt stellen dan kun je best vanaf NU de gegevens gaan bijhouden, totdat je klaar bent met instellen.

Echter als ik er achterkomt dat het huis later warm is, dan ik graag weten wat de ketel de afgelopen X aantal uur gedaan heeft. Dan moeten die gegevens wel ergens beschikbaar zijn en zul je dus waarschijnlijk 24/7 die data ergens op moeten slaan.

[iMars]

Verwijderd schreef op zaterdag 30 april 2016 @ 15:00:
Na dagen lange druk van ThinkPad (geintje) heb ik de oplossing opgeschreven in mijn TweakBlog.

Met een dosis IT kennis moeten jullie er wel uit kunnen komen denk ik. Het is niet zo heel moeilijk, maar het resultaat mag er wezen. Uiteraard werkt dit niet als Domoticz de PS=1 zet, maar dat wordt in de blog post wel duidelijk.

Ik hoor graag verbeteringen, bugs en andere kritiek zodat we het nog beter kunnen maken

ThinkPad heeft het net getest en heeft nu dezelfde oplossing draaien en zit nu gefrustreerd te wachten totdat er meer data beschikbaar is en ik voel de druk al om mijn P1/Slimmemeter oplossing ook te delen maar daar ben ik zelf nog niet mee klaar.

Even hardop denkend hier: is het niet mogelijk dat Domoticz na elke PS=1 commando een PS=0 commando als laatste erbij geeft?
Ik doe dat nu handmatig via de terminal:

Als ik dat een tijdje vol hou, zie ik dat otmonitor weer begint te loggen:

En dus ook Grafana weer begint te loggen:

[ThinkPad]

iMars schreef op zondag 01 mei 2016 @ 16:22:
[...]

Even hardop denkend hier: is het niet mogelijk dat Domoticz na elke PS=1 commando een PS=0 commando als laatste erbij geeft?
[...]

Misschien kun je het aandragen als verbetering in de Domoticz sourcecode. Misschien kun je het ook zelf aanpassen in de source: https://github.com/domoti...ardware/OTGWBase.cpp#L250 en dan Domoticz opnieuw compileren. Je zou eens kunnen testen wat er gebeurt als je een PS=1 doet en direct daarna een PS=0

Of Domoticz gewoon niet meer gebruiken om de OTGW uit te lezen Met Grafana heb je de logging al, de aansturing kun je evt. doen door commando's aan te roepen via otmonitor URL.

[ Voor 53% gewijzigd door ThinkPad op 01-05-2016 17:20 ]

[iMars]

ThinkPadd schreef op zondag 01 mei 2016 @ 16:45:
[...]

Misschien kun je het aandragen als verbetering in de Domoticz sourcecode. Misschien kun je het ook zelf aanpassen in de source: https://github.com/contac...dware/OTGWSerial.cpp#L170 en dan Domoticz opnieuw compileren. Je zou eens kunnen testen wat er gebeurt als je een PS=1 doet en direct daarna een PS=0

Of Domoticz gewoon niet meer gebruiken om de OTGW uit te lezen Met Grafana heb je de logging al, de aansturing kun je evt. doen door commando's aan te roepen via otmonitor URL.

Ik heb net de code doorspit en kwam dit tegen in OTGWBase.cpp:

code:

void OTGWBase::GetGatewayDetails()
{
    char szCmd[30];
    strcpy(szCmd, "PR=G\r\n");
    WriteInt((const unsigned char*)&szCmd, (const unsigned char)strlen(szCmd));
    strcpy(szCmd, "PR=I\r\n");
    WriteInt((const unsigned char*)&szCmd, (const unsigned char)strlen(szCmd));
    strcpy(szCmd, "PR=O\r\n");
    WriteInt((const unsigned char*)&szCmd, (const unsigned char)strlen(szCmd));
    strcpy(szCmd, "PS=1\r\n");
    WriteInt((const unsigned char*)&szCmd, (const unsigned char)strlen(szCmd));
}

Heb daar een issue voor ingediend
Maar nu zie ik dat de code online (ik had de master gedownload) al totaal anders is dan dat wat ik gedownload heb...

De reden dat ik alles met Domoticz wil aansturen is dat alles dan op 1 plaats zit en niet met losse apps.
Ik heb 1 interface waarin ik alles kan bedienen en met elkaar kan laten werken. Ook werkt het nu perfect samen met homebridge en Siri op mijn iPhone:
plaatje: Siri op iPhone
Edit: hopelijk ben ik de OTGW topic niet te veel aan het bevuilen (dit hoort meer thuis in de Domoticz topic )

[ Voor 3% gewijzigd door ThinkPad op 01-05-2016 17:21 . Reden: Even linkje gemaakt omdat plaatje vrij groot is ;-) ]

[ThinkPad]

iMars schreef op zondag 01 mei 2016 @ 17:15:
[...]
Maar nu zie ik dat de code online (ik had de master gedownload) al totaal anders is dan dat wat ik gedownload heb...
[...]

We zitten allebei op de verkeerde plek te kijken, dit is de officiële Domoticz repo: https://github.com/domoticz/domoticz/tree/master/hardware

[iMars]

ThinkPadd schreef op zondag 01 mei 2016 @ 17:19:
[...]

We zitten allebei op de verkeerde plek te kijken, dit is de officiële Domoticz repo: https://github.com/domoticz/domoticz/tree/master/hardware

Dat ziet er beter uit, precies hetzelfde als de master die ik heb gedownload: https://github.com/domoti...ardware/OTGWBase.cpp#L250

[iMars]

Aanpassing gemaakt in OTGWBase.cpp, gecompileerd, en gekopieerd naar mijn Rpi (backup van de oude gemaakt uiteraard) en het werkt als een tierelier

[Verwijderd]

iMars schreef op zondag 01 mei 2016 @ 21:34:
Aanpassing gemaakt in OTGWBase.cpp, gecompileerd, en gekopieerd naar mijn Rpi (backup van de oude gemaakt uiteraard) en het werkt als een tierelier
[afbeelding]

Ik vraag me wel af wat het gevolg is voor je OTGW, hij switch zo natuurlijk erg vaak van programma.

[iMars]

Verwijderd schreef op zondag 01 mei 2016 @ 21:55:
[...]


Ik vraag me wel af wat het gevolg is voor je OTGW, hij switch zo natuurlijk erg vaak van programma.

We zullen zien
Mijn issue hebben ze iig gesloten (crosspost???)
Ze opperde daar MQTT te gebruiken...

Eerst dit maar eens even aankijken

Edit:
Eerste bug van mijn aanpassing gevonden
De waardes worden niet meer geregistreerd in Domoticz. Het enige wat werkt, is de set point (ik kan dus de temperatuur bedienen, en dat vind ik het belangrijkste).
De gemeten temperatuur, boiler temperatuur e.d. worden niet meer geüpdate.
Ik denk dat ik de PS=0 te snel achter de PS=1 geef, waardoor Domoticz de tijd niet heeft om de update binnen te krijgen. Ik ga er een "msleep(1000)" voor zetten (volgens mij moet dat meer dan genoeg zijn).

Dit gebeurd er nu:

code:

03:07:48.205960  Command (via relay server, from 10.0.0.3:47301): SC=3:07/1
03:07:48.207766  Command (via relay server, from 10.0.0.3:47301): PR=G
03:07:48.209044  Command (via relay server, from 10.0.0.3:47301): PR=I
03:07:48.210471  Command (via relay server, from 10.0.0.3:47301): PR=O
03:07:48.211718  Command (via relay server, from 10.0.0.3:47301): PS=1
03:07:48.212906  Command (via relay server, from 10.0.0.3:47301): PS=0
03:07:48.345367  SC: 03:07/1
03:07:48.440167  PR: G=00
03:07:48.442333  PR: I=00
03:07:48.444179  PR: O=T15.00
03:07:48.445933  PS: 1
03:07:48.482361  00000010/00000000,10.00,00000011/00000011,100.00,PS: 0

Terwijl als ik handmatig een PS=1 geef, krijg ik meer informatie:

code:

03:07:32.504419  PS: 1
03:07:32.577486  00000010/00000000,10.00,00000011/00000011,100.00,28/43,15.00,0.00,0.00,20.69,50.00,49.00,0.00,38.00,70/40,70/20,60.00,90.00,0,0,0,0,0,0,0,0

De gegevens worden ruim binnen een seconde gegeven:

code:

2016-05-02 03:16:44.452 (Verwarming) Temp (Verwarming)
2016-05-02 03:16:44.498 (Verwarming) General/Percentage (Maximum Relative Modulation Level)
2016-05-02 03:16:44.502 (Verwarming) Thermostat (Thermostaat)
2016-05-02 03:16:44.535 (Verwarming) General/Percentage (Relative modulation level)
2016-05-02 03:16:44.536 (Verwarming) Temp (Room Temperature)
2016-05-02 03:16:44.561 (Verwarming) Temp (Boiler Water Temperature)
2016-05-02 03:16:44.585 (Verwarming) Temp (DHW Temperature)
2016-05-02 03:16:44.609 (Verwarming) Temp (Outside Temperature)
2016-05-02 03:16:44.611 (Verwarming) Temp (Return Water Temperature)
2016-05-02 03:16:44.635 (Verwarming) Thermostat (DHW Setpoint)
2016-05-02 03:16:44.637 (Verwarming) Thermostat (Max_CH Water Setpoint)

Morgen maar aanpassen en opnieuw compileren

[ Voor 73% gewijzigd door iMars op 02-05-2016 03:19 ]

[Verwijderd]

Ik snap alleen nog niet precies waarom je het doet. Ik heb de otgw op deze manier aan mijn domotica oplossing geknoopt. Ik gebruik dan wel een zipabox, maar zo veel verschillend van domoticz is dat nu ook weer niet.

otmonitor draait op een PI en zit vast aan de OTGW.
Python script stuurt elke wijziging op de OTGW door naar de Zipabox, daar heb ik als het ware een Virtuele Thermostaat.
Zipabox communiceert met de otmonitor doormiddel van de command pagina en op die manier zet ik de setpoint en rest ik hem terug naar het klok programma. Dit gaat via HTTP requests

Mijn verwarming regel ik dus vanuit mijn Zipabox, dus op 1 plaats.

[iMars]

Verwijderd schreef op maandag 02 mei 2016 @ 06:41:
Ik snap alleen nog niet precies waarom je het doet. Ik heb de otgw op deze manier aan mijn domotica oplossing geknoopt. Ik gebruik dan wel een zipabox, maar zo veel verschillend van domoticz is dat nu ook weer niet.

otmonitor draait op een PI en zit vast aan de OTGW.
Python script stuurt elke wijziging op de OTGW door naar de Zipabox, daar heb ik als het ware een Virtuele Thermostaat.
Zipabox communiceert met de otmonitor doormiddel van de command pagina en op die manier zet ik de setpoint en rest ik hem terug naar het klok programma. Dit gaat via HTTP requests

Mijn verwarming regel ik dus vanuit mijn Zipabox, dus op 1 plaats.

Dit heb ik nog niet werkend gekregen op Domoticz, vandaar dat ik het op deze manier probeer

code:

void OTGWBase::GetGatewayDetails()
{
        char szCmd[30];
        strcpy(szCmd, "PR=G\r\n");
        WriteInt((const unsigned char*)&szCmd, (const unsigned char)strlen(szCmd));
        strcpy(szCmd, "PR=I\r\n");
        WriteInt((const unsigned char*)&szCmd, (const unsigned char)strlen(szCmd));
        strcpy(szCmd, "PR=O\r\n");
        WriteInt((const unsigned char*)&szCmd, (const unsigned char)strlen(szCmd));
        strcpy(szCmd, "PS=1\r\n");
        WriteInt((const unsigned char*)&szCmd, (const unsigned char)strlen(szCmd));
        sleep(1);
        strcpy(szCmd, "PS=0\r\n");
        WriteInt((const unsigned char*)&szCmd, (const unsigned char)strlen(szCmd));
}

Regel 252, 253 en 254 toegevoegd en nu werkt het perfect!

[ Voor 31% gewijzigd door iMars op 02-05-2016 19:20 ]

[Verwijderd]

maxnl schreef op vrijdag 08 april 2016 @ 22:10:
Vandaag wat PCBtjes met mijn externe 24v adapter aanpassing binnen gehad, die ik bij itead had besteld.
Wilde net solderen en testen, maar moet eerst nog even kijken of ik ergens een 15k weerstandje heb liggen, want ook de verkeerde van Conrad ontvangen.


[...]


[afbeelding]

Bij mij een 82R

Het lek is nog niet boven, hier ook een 82R ontvangen

[maxnl]

Verwijderd schreef op dinsdag 03 mei 2016 @ 21:01:
Het lek is nog niet boven, hier ook een 82R ontvangen

Overigens hebben ze bij mij inmiddels wel netjes de juiste nagestuurd.

[ Voor 20% gewijzigd door maxnl op 03-05-2016 21:20 ]

[Verwijderd]

Goed nieuws, heb ze net ook een berichtje gestuurd. 15k heb ik ook nog wel liggen alleen even zoeken morgen.

[bluewalk]

Ik heb gisteren een printje in elkaar gesoldeerd om een ESP te gaan gebruiken voor mijn OTGW met de esp-link firmware.
OTGW TX -> ESP RX werkt volgens voltage divider zoals deze:

EXP TX -> OTGW RX werkt niet. Eerst geprobeerd om te kijken of de ESP TX met 3.3v genoeg was voor de 5v RX van de OTGW, bleek niet het geval te zijn want hij deed niets.
Vervolgens het boardje omgebowd volgens dit schema voor TX echter doet hij nog steeds niets.


Het vreemde is, als ik het boardje aansluit op een 5V USB-TTL kabel dan werkt alles naar behoren, zodra ik hem aansluit op de OTGW gebeurd er helaas niets.
Misschien toch maar voor een kant en klare oplossing gaan zoals deze. Of heeft iemand nog een goede ingeving?

[maxnl]

cyberde schreef op donderdag 05 mei 2016 @ 13:12:
Misschien toch maar voor een kant en klare oplossing gaan zoals deze. Of heeft iemand nog een goede ingeving?

In de download link op die eBay pagina staat ook het schema van dat ding.
Deel voor level shifting:



Zou zeggen bouw dat eens na. Denk dat je voor Q1 en Q2 een 2N7000 kan gebruiken.


Er staat verder wel daadwerkelijk 3.3v op de ESP TX? Dat niet de voeding kuren heeft.

[ Voor 6% gewijzigd door maxnl op 05-05-2016 13:42 ]

[bluewalk]

maxnl schreef op donderdag 05 mei 2016 @ 13:40:
[...]


In de download link op die eBay pagina staat ook het schema van dat ding.
Deel voor level shifting:

[afbeelding]

Zou zeggen bouw dat eens na. Denk dat je voor Q1 en Q2 een 2N7000 kan gebruiken.


Er staat verder wel daadwerkelijk 3.3v op de ESP TX? Dat niet de voeding kuren heeft.

Thnx voor je antwoord, hier helaas geen 2N7000 liggen, voor het huidige circuit een 2N2222 gebruikt. Op de TX van de ESP staat 3.28v, waarbij er uiteindelijk op de TX na de transistor 4.9nogwat volt staat, zou dus goed moeten zijn?

edit
Ben er uit, het lijkt er op dat de ESP (01) eerst gestart moet worden en daarna de TX aan de RX van de OTGW gekoppeld moet worden.
Het starten van de ESP stuurt even wat meuk over serial er uit waardoor de RX van de OTGW het padje af raakt.
Wordt wel lastig want ik voedt de ESP vanaf de OTGW. Eens kijken of ik niet de TX+RX van de ESP over GPIO0 en GPIO2 kan sturen met de esp-link firmware en het boardje kan aanpassen.

[ Voor 24% gewijzigd door bluewalk op 05-05-2016 14:10 ]

[maxnl]

Geloof dat GPIO 13-15 de alternative UART pinnen zijn, maar die moeten dan wel toegankelijk op je ESP bordje zijn.
Anders zou ik eerder kijken of je niet een van de GPIOs aan de reset van de OTGW kan knopen.

[bluewalk]

maxnl schreef op donderdag 05 mei 2016 @ 14:26:
Anders zou ik eerder kijken of je niet een van de GPIOs aan de reset van de OTGW kan knopen.

Yes, dat was een heel goed idee. Zojuist m'n boardje aangepast, pinheaders op de OTGW gesoldeerd en aangesloten. Werkt perfect nu!


Het is geen mooi boardje, maar om er eentje te ontwerpen en 12 te laten maken vond ik wat overkill

[ Voor 31% gewijzigd door bluewalk op 05-05-2016 21:21 ]

[balk]

Ik heb mijn ervaring met OTGW/ESP/Domoticz tot nu toe gevangen in een blog. Ik gebruik een iets luxer ESP bordje.

[Matis]

balk schreef op vrijdag 06 mei 2016 @ 10:35:
Ik heb mijn ervaring met OTGW/ESP/Domoticz tot nu toe gevangen in een blog. Ik gebruik een iets luxer ESP bordje.

Mooie beknopte blog Wat ik niet kan terugvinden is je ervaring met de el-cheapo USB 2 serial kabel. Heb je die überhaupt gebruikt?

[balk]

Matis schreef op vrijdag 06 mei 2016 @ 11:59:
[...]

Mooie beknopte blog Wat ik niet kan terugvinden is je ervaring met de el-cheapo USB 2 serial kabel. Heb je die überhaupt gebruikt?

Dankje
Die kabel had ik nodig om de ESP te flashen, en ook om de OTGW te flashen. Vanuit otmonitor kan je een nieuwe firmware er op zetten en in het flash proces moet je de OTGW een keer power cyclen terwijl de connectie met otmonitor bewaard blijft. Omdat mijn ESP op de voeding van de OTGW zit, gaat die verbinding ook verloren bij een power cycle. Ik zal het toevoegen.

[Matis]

Thnx voor de reply. Ik heb de OTGW uiteindelijk met een PIC programmer geflasht.
Ik wil uiteindelijk de kabel gebruiken voor de data. Het is van de zotten om van TTL naar RS232 te gaan om vervolgens naar 5 volt USB te gaan. Jammer dat het niet direct op de 3V3 van de GPIO van de RPi gaat.

[bluewalk]

Je kan ook gewoon een reset knop aan je OTGW hangen. Hoef je bij het flashen niet te power cyclen en blijf je esp levend. Als je dan de reset aan een gpio hangt zoals op advies van maxnl dan kan je de OTGW remote flashen en resetten

[Verwijderd]

Even voor mijn beeldvorming.

Als je een PIC programmer hebt is dan 'otmonitor' voldoende om de 'gateway.hex' in de PIC te schieten?
Of moet de PIC eerst nog geladen worden met bootsoftware?

[rippiedoos]

Verwijderd schreef op dinsdag 10 mei 2016 @ 14:22:
Even voor mijn beeldvorming.

Als je een PIC programmer hebt is dan 'otmonitor' voldoende om de 'gateway.hex' in de PIC te schieten?
Of moet de PIC eerst nog geladen worden met bootsoftware?

Met die PIC-programmer schiet je rechtstreeks software in de PIC. Dus de gateway.hex schiet je daarmee in de PIC.

Mocht je nou niet zo'n programmer hebben kun je mij een DM sturen en dan regelen we wat. Heb ik al voor meerdere tweakers gedaan hier.

[Verwijderd]

rippiedoos schreef op dinsdag 10 mei 2016 @ 14:27:
[...]


Met die PIC-programmer schiet je rechtstreeks software in de PIC. Dus de gateway.hex schiet je daarmee in de PIC.

Mocht je nou niet zo'n programmer hebben kun je mij een DM sturen en dan regelen we wat. Heb ik al voor meerdere tweakers gedaan hier.

Top, maar dat inschieten wordt door otmonitor gedaan of heb ik daar speciale software voor nodig?

[rippiedoos]

Verwijderd schreef op dinsdag 10 mei 2016 @ 14:28:
[...]


Top, maar dat inschieten wordt door otmonitor gedaan of heb ik daar speciale software voor nodig?

Daar heb je een aparte programmer voor nodig. Nadat de eerste versie van gateway.hex of diagnostic.hex in de PIC zit kun je met otmonitor de volgende versies in de PIC zetten. Maar de eerste keer moet het met een PIC-programmer zoals de pickit2 of andere speciale PIC-programmers.

[iMars]

Vraagje over Grafana. Ik zit nu in het buitenland en zat net even op mijn interface te kijken. Maar nu vraag ik me af: Welke tijd wordt er gebruikt?
Foto

Het was hier rond 11:11 en in Nederland 17:11 ... Ik had verwacht/gehoopt de Nederlandse tijd te zien... Maar ik zie data van rond 17:00 met de tijd van rond 11:00 (6u tijdsverschil)

Kan ik dat ergens aanpassen?

[Verwijderd]

iMars schreef op dinsdag 10 mei 2016 @ 17:31:
Vraagje over Grafana. Ik zit nu in het buitenland en zat net even op mijn interface te kijken. Maar nu vraag ik me af: Welke tijd wordt er gebruikt?
Foto

Het was hier rond 11:11 en in Nederland 17:11 ... Ik had verwacht/gehoopt de Nederlandse tijd te zien... Maar ik zie data van rond 17:00 met de tijd van rond 11:00 (6u tijdsverschil)

Kan ik dat ergens aanpassen?

Tandwiel -> Settings -> TimeZone..

Geen idee wat het doet trouwens, maar misschien is dit wat je zoekt.

[ThinkPad]

iMars schreef op dinsdag 10 mei 2016 @ 17:31:
Vraagje over Grafana. Ik zit nu in het buitenland en zat net even op mijn interface te kijken. Maar nu vraag ik me af: Welke tijd wordt er gebruikt?
Foto

Het was hier rond 11:11 en in Nederland 17:11 ... Ik had verwacht/gehoopt de Nederlandse tijd te zien... Maar ik zie data van rond 17:00 met de tijd van rond 11:00 (6u tijdsverschil)

Kan ik dat ergens aanpassen?

Dat plaatje ziet er raar uit.

Waarom (lijkt) je ketel stoken? Aanvoer van 70 graden terwijl het 26 graden is in huis? En setpoint staat hele dag op 15, dus: why???

[ Voor 3% gewijzigd door ThinkPad op 10-05-2016 19:46 ]

[iMars]

Verwijderd schreef op dinsdag 10 mei 2016 @ 18:26:
[...]


[afbeelding]

Tandwiel -> Settings -> TimeZone..

Geen idee wat het doet trouwens, maar misschien is dit wat je zoekt.

Thnx, zal ik zo gelijk ff naar kijken.

ThinkPadd schreef op dinsdag 10 mei 2016 @ 19:39:
[...]

Dat plaatje ziet er raar uit.

Waarom (lijkt) je ketel stoken? Aanvoer van 70 graden terwijl het 26 graden is in huis? En setpoint staat hele dag op 15, dus: why???

Die pieken is warmwater gebruik. M'n vriendin is thuis en die heeft o.a. gedouched

[juptache]

juptache schreef op zondag 10 april 2016 @ 13:53:
Zou ik deze USB-TTL module kunnen gebruiken om m'n OTGW aan te sluiten met een USB kabel? Heb deze namelijk nog liggen van een ander projectje, dus zou mooi zijn als ik die kan hergebruiken. Hij kan in ieder geval op de 5v aangesloten.

Om mijn eigen vraag te beantwoorden: ik krijg het niet werkend met die module. Nu dus wachten op de USB-TTL kabel, dat gaat waarschijnlijk nog wel even duren

[rippiedoos]

juptache schreef op woensdag 11 mei 2016 @ 09:42:
[...]

Om mijn eigen vraag te beantwoorden: ik krijg het niet werkend met die module. Nu dus wachten op de USB-TTL kabel, dat gaat waarschijnlijk nog wel even duren

Wat werkt wel en niet met die kabel trouwens? Ik heb vaker gezien dat 5v, GND, TX en RX op de OTGW-zelf aangesloten moeten worden. Met een andere adapter heb ik het in elk geval niet werkend gekregen als ik 5v NIET had aangesloten. Zodra ik alle 4 de kabels had aangesloten werkte het. Wel natuurlijk de TX en RX altijd maar verkeerd aangesloten, maar dat is snel gefixt natuurlijk.

[Matis]

Ja, deze moet direct op de PIC worden aangesloten, niet op de output pinnen van de MAX232. De MAX232 converteert het signaal namelijk van 5V naar +- 30V
Heb je gecontroleerd dat de jumper op jouw kabel op 5V staat en niet op 3V3?

[DJFliX]

Hardwarevraagje: Ik had een werkende OTGW gedurende ongeveer 2 weken. Ik heb e kit van kiwi-electronics en die heb ik zelf gesoldeerd. Een paar dagen geleden stopte de gateway en kreeg ik een F203 error op mijn Remaha iSense. In retrospect bleek dit door een kabelbreuk veroorzaakt te zijn . Maar goed, ik krijg sinds ik de kabels naar de thermostaat en ketel weer vastgemaakt heb geen enkel teken van leven uit de gateway. Omdat ik nu toch wel nieuwsgierig was naar de oorzaak begon ik hiermee: http://otgw.tclcode.com/debugging.html#power, en daar kwam ik er al vrij snel achter dat mijn L7805 geen 5V maar ~2.7V output geeft. Ik heb even naar de schematic (http://otgw.tclcode.com/schematic.html#layout) gekeken, maar kan zo 1-2-3 geen duidelijke aanwijzing vinden waarom die output 2.7V zou kunnen zijn.

Welke zaken zou ik nog kunnen doormeten om de oorzaak van de lage output van de 7805 te vinden? Of doe ik er goed aan om deze 7805 als defect te beschouwen en er gelijk een R-78E5.0-0.5 op te zetten?

[naftebakje]

Ofwel trekt er iets teveel stroom, of de 7805 is defect. Ik zou de 7805 vervangen (als er niets rookt of heet wordt).

[ Voor 17% gewijzigd door naftebakje op 13-05-2016 07:59 ]

[Matis]

Je zou ook nog het voltage voor de 7805 kunnen controleren (secundair van de EI30). Die zou onder belasting 15V moeten zijn. Nu is de 7805 nogal tolerant als het gaat over zijn input voltage, maar misschien is er iets in de trafo stuk of hij schiet in de kortsluitingsbeveiliging.

[ Voor 8% gewijzigd door Matis op 13-05-2016 10:03 ]

[DJFliX]

naftebakje, Matis, thanks! Ik ga er vanavond even naar kijken en laat het weten als ik meer weet. Ik bestel al wel vast een nieuwe 7805, je weet nooit waar hij handig voor is .

Edit: net even gemeten, tussen Pin 1 en 2 van de 7805 meet ik 24.3V. Tussen 2 en 3 nog steeds 2.7V. Dit is met de USB-to-Serial adapter aangesloten op mijn pc. Als ik deze los trek meet ik 5V tussen pin 2 en 3, en nog steeds 24.3V op 1 en 2. Ik begin te twijfelen aan de USB-to-Serial kabel die ik bij de kit kreeg, maar als ik een loopback connectie maak werkt die adapter wel weer prima . Maar met deze kennis lijkt het er wel op dat het vervangen van de 7805 geen wereld van verschil zal gaan maken . Heeft iemand nog andere suggesties voor wat ik nog door kan meten? Heb helaas geen andere USB-to-UART adapter liggen die 5V tolereert, die ligt nog op werk.

Edit2: Heb ook nog even met de IR-thermometer gekeken (goedkoop chinees ding, niet zo'n mooie FLIR helaas ) en geen van de componenten wordt veel warmer dan een paar graden boven kamertemperatuur.

iMars schreef op dinsdag 10 mei 2016 @ 17:31:
Vraagje over Grafana. Ik zit nu in het buitenland en zat net even op mijn interface te kijken. Maar nu vraag ik me af: Welke tijd wordt er gebruikt?
Foto

Het was hier rond 11:11 en in Nederland 17:11 ... Ik had verwacht/gehoopt de Nederlandse tijd te zien... Maar ik zie data van rond 17:00 met de tijd van rond 11:00 (6u tijdsverschil)

Kan ik dat ergens aanpassen?

Misschien weet je dit al, maar InfluxDB gebruikt in principe altijd UTC tijd intern. Pas in Grafana worden de timestamps omgerekend naar lokale (of ingestelde) tijdzone. Wat je ziet in Grafana is dus altijd UTC + Offset.

[ Voor 109% gewijzigd door DJFliX op 13-05-2016 21:02 ]

[DJFliX]

Vandaag heb ik de nieuwe 7805 geinstalleerd, waar 5V op moet staan meet ik nu ook echt 5V en de OTGW is inmiddels weer in de kast geïnstalleerd! naftebakje en Matis, thanks!

[Tele]

Het is alweer een tijdje terug, maar ik had nog toegezegd om een revisie van m'n eerdere otgw te maken. Bij deze alvast de schema's, de pcb komt zeer binnenkort Onderstaande is als voorbeeld de nodeMCU wifi variant;









Hierin heb ik alle wensen proberen te combineren in een aantal mogelijke bestukvarianten. Er is plaats voor een nodeMCU wifi module of een USR TCP232T ethernet module. Verder kan hij met 5V via de nodeMCU usb aansluiting gevoed worden, of extern, bijvoorbeeld vanaf de ketel.

[Thedr]

Ziet er goed uit Tele! Geen idee of mijn ketel genoeg voeding kan leveren, maar ben zeker geinteresseerd in de variant met nodeMCU en 5V voeding

[MLS]

@Tele, mooi project! Ik ben erg geïnteresseerd in de PCB-files, dan ga ik binnenkort even klussen hopelijk ook over op Opentherm via wifi
Misschien kan ik zelfs nog wat correcties injecteren op de Evohome Opentherm-implementatie met de tijd, maar dat is een later projectje.

[cville]

Tele schreef op dinsdag 17 mei 2016 @ 22:32:
Het is alweer een tijdje terug, maar ik had nog toegezegd om een revisie van m'n eerdere otgw te maken. Bij deze alvast de schema's, de pcb komt zeer binnenkort Onderstaande is als voorbeeld de nodeMCU wifi variant;

[afbeelding]

[afbeelding]

[afbeelding]

[afbeelding]

Hierin heb ik alle wensen proberen te combineren in een aantal mogelijke bestukvarianten. Er is plaats voor een nodeMCU wifi module of een USR TCP232T ethernet module. Verder kan hij met 5V via de nodeMCU usb aansluiting gevoed worden, of extern, bijvoorbeeld vanaf de ketel.

Erg leuk; door de verschillende voedingsvarianten begin ik steeds meer van de OTGW te begrijpen. Wat ik niet begrijp is het volgende: als je een NodeMCU gaat gebruiken waarom heb je dan nog een PIC nodig? Ik begrijp wel dat de schakeling en software dan anders moeten maar het lijkt me dat een op een NodeMCU gebaseerde OTGW met veel minder onderdelen toe zou kunnen, eenvoudiger te programmeren is en gewoon via een USB voeding van spanning voorzien kan worden.

Wat mis ik?

[Matis]

De PIC leest de communicatie tussen de ketel en de thermostaat en waar nodig communiceert de PIC zelf ook nog met de ketel. Deze informatie loopt over het opentherm protocol. Dat is een realtime protocol, vandaar dat de PIC er op zit, die kan dat realtime gedrag garanderen.
De informatie wordt door de PIC omgezet in een "leesbaar" formaat en via de seriele poort van de PIC de boze wereld in geslingerd.
Normaliter (in het origineel) verzorgde een MAX232 de vertaalslag (qua potentiaalverschil) tussen de PIC en een PC. Die moest dan op de seriele poort van de PC aangesloten worden.
De NodeMCU zendt ipv over de seriële kabel de data via WiFi.

[RSpaargaren]

cyberde schreef op zaterdag 07 mei 2016 @ 09:55:
Je kan ook gewoon een reset knop aan je OTGW hangen. Hoef je bij het flashen niet te power cyclen en blijf je esp levend. Als je dan de reset aan een gpio hangt zoals op advies van maxnl dan kan je de OTGW remote flashen en resetten

Ik probeer nu de gateway erin te laden met de openterm monitor via een esp connectie. Ik heb verbinding maar hij wacht op een reset...? Moet ik hierbij de reset ff verbinden of is de stekker eruit voldoende?

[bluewalk]

RSpaargaren schreef op zaterdag 21 mei 2016 @ 18:50:
[...]

Ik probeer nu de gateway erin te laden met de openterm monitor via een esp connectie. Ik heb verbinding maar hij wacht op een reset...? Moet ik hierbij de reset ff verbinden of is de stekker eruit voldoende?

Nee je moet de reset pin verbinden met een vrije GPIO van de ESP, deze GPIO selecteren in esp-link als reset GPIO.
Vervolgens kan je in de esp-link webgui de PIC resetten. Zo blijft je ESP in leven, je serial/tcp verbinding ook en toch reset de OTGW. Trek je je stekker er uit, dan is ook Openterm monitor zijn verbinding kwijt en dat wil je niet

[ Voor 21% gewijzigd door bluewalk op 22-05-2016 10:47 ]

[RSpaargaren]

@cyberde thanks voor je uitleg. Dat draadje zal ik nog ff aanleggen voordat ik de doos sluit. Heb het nu met twee losse draadjes gedaan.

[naftebakje]

Matis schreef op zaterdag 21 mei 2016 @ 17:01:
De PIC leest de communicatie tussen de ketel en de thermostaat en waar nodig communiceert de PIC zelf ook nog met de ketel. Deze informatie loopt over het opentherm protocol. Dat is een realtime protocol, vandaar dat de PIC er op zit, die kan dat realtime gedrag garanderen.
De informatie wordt door de PIC omgezet in een "leesbaar" formaat en via de seriele poort van de PIC de boze wereld in geslingerd.
Normaliter (in het origineel) verzorgde een MAX232 de vertaalslag (qua potentiaalverschil) tussen de PIC en een PC. Die moest dan op de seriele poort van de PC aangesloten worden.
De NodeMCU zendt ipv over de seriële kabel de data via WiFi.

En daar komt ook nog bij dat de PIC intern 2 comparators heeft, die nodig zijn om opentherm te kunnen lezen, maar ook blijven werken als de PIC software vast zou lopen; je ketel-thermostaat verbinding loopt niet vast en zonder PIC moet je toch weer die comparatoren als extra component plaatsen.

[Tele]

De pcb is bijna klaar, alvast een tipje van de sluier

[MLS]

@Tele: Mooi compact! Ziet er top uit

[mymind*]

Gisteren heb ik mijn OTGW op m'n CV aangesloten. Alles lijkt/leek te werken. De data kwam netjes binnen en met otmonitor zie ik ook netjes de grafieken. De data, bijvoorbeeld de retourtemperatuur, klopte en gaf de juiste waarde aan.

Daarna een poging gedaan om het geheel in Domoticz op te nemen maar dat lukte niet. De devices verschenen niet, misschien heeft het er mee te maken dat ik (nog) geen modulerende thermostaat heb. Alles weer uit Domoticz gehaald.

Het aparte is dat als ik nu in otmonitor te hoge waarden terugkrijg. De retourtemp geeft nu 46 graden terug en hij lijkt niet daaronder te komen. Is er misschien door Domoticz een setting gedaan die teruggedraaid moet worden? Zie ik misschien een setting over het hoofd?

Edit: Hij lijkt nu wel heel langzaam te zakken. Kortgeleden heb ik wel warm water gebruikt (douchen). Kan het zijn dat retour water temp ook weergeeft wat de temperatuur in het warmwater circuit weergeeft oid?

Het lijkt echt een offset te zijn van precies 20 graden. Is deze offset ergen in te stellen?

Hij is toch verder gezakt. Ik vermoed dat de data pas bij communicatie tussen een openthem thermostaat goed bijgewerkt wordt.

[ Voor 22% gewijzigd door mymind* op 25-05-2016 11:50 ]

[naftebakje]

Als ik me niet vergis wordt door domotics de OTGW in een "polling" status gezet, dus enkel data doorsturen als dit aangevraagd wordt, iets met "PS=" als ik het goed herinner.

[ThinkPad]

Domoticz pollt inderdaad de OTGW, hij stuurt een PS=1 commando. Hierdoor zal de OTGW niet meer constant alle berichten die hij ontvangt uitspugen, maar is hij stil, totdat Domoticz weer een PS=1 stuurt en daarmee een samenvatting van de belangrijkste waarden opvraagt.

Domoticz en otmonitor samen werkt dus niet lekker. Gelukkig valt het wel op te lossen door wat extra code toe te voegen in de Domoticz sourcecode, zie iMars in "[OTGW] OpenTherm gateway" en iMars in "[OTGW] OpenTherm gateway"

[mymind*]

naftebakje schreef op woensdag 25 mei 2016 @ 12:31:
Als ik me niet vergis wordt door domotics de OTGW in een "polling" status gezet, dus enkel data doorsturen als dit aangevraagd wordt, iets met "PS=" als ik het goed herinner.

ThinkPadd schreef op woensdag 25 mei 2016 @ 12:35:
Domoticz pollt inderdaad de OTGW, hij stuurt een PS=1 commando. Hierdoor zal de OTGW niet meer constant alle berichten die hij ontvangt uitspugen, maar is hij stil, totdat Domoticz weer een PS=1 stuurt en daarmee een samenvatting van de belangrijkste waarden opvraagt.

Domoticz en otmonitor samen werkt dus niet lekker. Gelukkig valt het wel op te lossen door wat extra code toe te voegen in de Domoticz sourcecode, zie iMars in "[OTGW] OpenTherm gateway" en iMars in "[OTGW] OpenTherm gateway"

Thanks, Als ik een PS=0 stuur gaat hij weer automatisch data verwerken in otmonitor. Domoticz heb ik uitgeschakeld.

Het lijkt er op dat de ketel in de standby modus (geen verwarming of warmtevraag) de waarden van b.v. de temp niet meer update.

[Verwijderd]

Tele schreef op dinsdag 24 mei 2016 @ 21:56:
De pcb is bijna klaar, alvast een tipje van de sluier

[afbeelding]

Ziet er goed uit! Ben benieuwd

[m-ruiter227]

Tele schreef op dinsdag 24 mei 2016 @ 21:56:
De pcb is bijna klaar, alvast een tipje van de sluier

[afbeelding]

Kan niks amders zeggen dan

Kan niet wachten op meeeeeeeer !

[Templar]

Tele schreef op dinsdag 24 mei 2016 @ 21:56:
De pcb is bijna klaar, alvast een tipje van de sluier

[afbeelding]

Ik zie dat je kan kiezen tussen een DIP of SOIC package?

[Tele]

Templer schreef op zondag 29 mei 2016 @ 13:57:
[...]
Ik zie dat je kan kiezen tussen een DIP of SOIC package?

Klopt, ik heb het zelf niet zo op DIP

Ik ben een eind klaar met het ontwerpje. Alle bestanden zijn hier te vinden. De Altium bronbestanden volgen nadat ik deze heb opgeschoond.

Er zijn heel wat varianten te verzinnen, ik heb als voorbeeld 5 soorten in de documentatie toegevoegd. Er is te kiezen uit 3 soorten Led's, ethernet of wifi, DIP of SOIC uC, twee behuizingen, 3 soorten voedingsspanning,..

Dit voornamelijk als gevolg van de feedback hier, ik hoop dat er voor iedereen wat tussen zit. Ikzelf zal er voorlopig niet aan toe komen om de pcb's te assembleren, dus ik hoop dat iemand hier het aandurft

Als behuizing ben ik op deze twee uitgekomen waartussen gekozen kan worden, beide gatenpatronen zitten in de pcb;



Verder is het ontwerp dit keer niet beperkt tot Conrad, maar juist afgestemd op Farnell. Alle bestelnummers van Farnell staan ook in de bom's. Als iemand alle beschikbare conrad bestelnummers wilt opzoeken zal ik deze erbij vermelden.

Kijk eens rond in het mapje, ik ben benieuwd wat jullie ermee kunnen!

[Matis]

[MLS]

Top! De Altium-bestanden zouden zeker helpen om nog wat te schuiven met traces en via diameters om hem door een beperkte proto-machine te krijgen.

[remcoXP]

Supergaaf...
Ik ben benieuwd wanneer iemand dit als inkoopactie / solderservice of kant en klaar gaat aanbieden.
ook ben ik benieuwd naar de totaalkosten.

[m-ruiter227]

Ziet er puik uit. Als mn homeys ooit stabiel worden ga ik hem zeker maken.
Zal morgen eens kijken waar de printjes goedkoop gemaakt kunnen worden.
Uit China duurt tegewoordig ook nig maar 1 tot max 2 weken

[Tele]

Ik heb het complete Altium project er ook bijgezet

https://github.com/T3le/otgw/tree/master/rev1

De bronbestanden kunnen met de gratis Altium Designer viewer ook bekeken worden.

Zoals eerder gezegd zal ik er voorlopig niet aan toe komen om er 1tje in elkaar te bakken, dus er kunnen nog foutjes naar boven komen wanneer je er eentje bouwt....

[ Voor 19% gewijzigd door Tele op 01-06-2016 22:19 ]

[tyfoon_2]

Ivm met een nieuwe vloerverwarming in de keuken (met eigen pomp) wil ik eigenlijk de pomp van de vloerverwarming alleen maar laten lopen als ook de pomp van de CV loopt. Weet iemand welke variabele/parameter ik dan het best kan kijken. Ik was op zoek naar iets van statusPump of zo maar die lijkt er niet te zijn.

[ThinkPad]

Je kunt kijken naar de Flame Status (brand het vlammetje in de ketel) en naar de Central Heating mode (is de CV bezig voor verwarming? anders is hij bezig voor warm water bereiding). En misschien nog kijken naar de aanvoertemperatuur.

http://otgw.tclcode.com/otmonitor1.png

IF Flame = On AND CentralHeatingMode = On
THEN vloerverwarmingpomp = On
ELSE vloerverwarmingpomp = Off (al wil je hier misschien een soort van nalooptijd van maken, dat de pomp nog 5 min blijft draaien ofzo).

[ Voor 13% gewijzigd door ThinkPad op 12-06-2016 10:29 ]

[tyfoon_2]

Dank. Gaan we eens mee aan de slag

[HyperBart]

Weet iemand of dit dingetje nog eens kant en klaar bij Kiwi komt?

Ik heb namelijk niet veel zin om het allemaal bij elkaar te solderen en die PIC te programmeren, kant en klaar is wel zo fijn.

Ik heb in de afgelopen maanden al een paar keer gekeken of de OTGW in USB verkrijgbaar was maar voorlopig nog niets. Kijk er naar uit om dit in de nieuwe woning met de Remeha Calenta 40 te plotten in Grafana.

[originalmycroft]

Jaren terug al deze gateway aangeschaft, destijds lukte het niet om met een iSense de thermostat setpoint te veranderen.

Nu opnieuw aangesloten, iets andere setup:

-Rehema Avanta CW5
-Honeywell wireless round modulation thermostaat

Ik zie alle messages tussen thermostaat en ketel langskomen, de gateway geeft alles goed door.

PR=M geeft PR : M = G

Als ik op m'n thermostaat de temperatuur verhoog, springt de ketel gelijk aan.

Als ik via TT=30 of TC= 30 dit probeer, bevestigt de gateway het met TT : 30.00

Maar...... de kachel springt niet aan, het lijkt alsof hij de nieuwe setpoint niet injecteert.

Kan dit een timing issue zijn? Moet ik ergens een instelling veranderen?

Al veel gebladerd door het forum maar kan niemand vinden met hetzelfde probleem.

[ThinkPad]

Heb je de firmware al wel eens bijgewerkt, als je zegt dat je het ding al jaren hebt?

Wat voor PIC chip zit er in de jouwe eigenlijk? Want ergens een tijd terug is men overgestapt naar een nieuwere PIC chip om nieuwere firmware mogelijk te maken. Helaas kun je niet zomaar een nieuwere chip op jouw PCB drukken, de volgorde van de pinnetjes is anders meen ik.

[originalmycroft]

Ik heb een PIC16F88I/P, en er draait firmware van oktober 2015 op. Heb hem inderdaad opnieuw geflashed.

Mijn bord heeft revisie B, volgens mij ook wat er nu nog geleverd wordt, klopt dat?

Kan het zijn dat er in die PIC iets niet lekker zit? /lijkt me vreemd aangezien hij verder wel gewoon functioneert/ anders kan ik nog proberen een nieuwe PIC te kopen en te programmeren.

[ThinkPad]

Dan heb je de nieuwste PIC idd. De firmware versie van oktober 2015 (4.2.5) is idd nieuwste.

Wat er dan verkeerd gaat weet ik ook niet. Dat het destijds met je iSense niet lukte ligt aan de firmware. Ik had een iSense v19 waarmee ik ook het setpoint niet kon overriden. Daarna op Marktplaats een v28 gekocht en daarmee lukt het wel (je moet wel iets van 'Externe toegang' aanzetten in de thermostaat. Is eerder in dit topic wel besproken).

Heb je geen andere thermostaat om het mee te proberen?