Ziggy

3.0.0 av appen bruker en URL parameter 

&minUpdatedAt=2024-01-09T20%3A15%3A57%2B0100

for å begrense stasjoner (og datamende) overført til de som er endret etter dette tidspunktet. Tilsvarer

&minUpdatedAt=2024-01-09T20:15:57+0100

med ":" og "+" URL-enkodet.

De som allikevel setter opp noe som tar vare på states mellom requests kan vurdere å ta dette i bruk.

1 hour ago, nle said:

Jeg får ikke noe key som kan brukes iallefall, jeg får følgende output fra https://api.drivstoffappen.no/api/v1/authorization-sessions:

 

# curl -H 'Content-Type: application/json' -H 'X-CLIENT-ID: com.raskebiler.drivstoff.appen.ios' -H 'Accept: */*' -H 'User-Agent: Drivstoffappen/3.0.0 (com.raskebiler.drivstoff.appen; build:305; iOS 17.2.1) Alamofire/5.4.4' -H 'Accept-Language: en-NO;q=1.0, nb-NO;q=0.9' --compressed -H 'Connection: keep-alive' 'https://api.drivstoffappen.no/api/v1/authorization-sessions'

{"id":<tall ##>,"authorizationId":<tall ##>,"token":"<token ser slik ut: 237faA88-s90a-2eee-b31d-188244e6ce11">,"createdAt":"2024-01-13T13:25:03.000+0000","expiresAt":"2024-01-13T19:25:03.000+0000","deleted":0}%

 

Og "token" kan ikke brukes som ny API key (X-API-KEY). Noe jeg misser?

token 237faA88-s90a-2eee-b31d-188244e6ce11 brukes av appen til å generere en ny API-nøkkel, man kan jo tippe vha en kryptografisk algoritme som ikke lett kan knekkes.

18 minutes ago, nle said:

Ok, men da er det vel «bare» å bruke den midlertidige keyen? Og refreshe.

Ja, antar det.

8 hours ago, VikingOy said:

@Ziggy dersom dine observasjoner og konklusjoner riktige, - og det tror jeg de er - betyr dette da at man heller ikke kan kjøpe en "lovlig" API nøkkel ?  M.a.o. at Drivstoffappen aldri har tenkt til å åpne for betalte tredje-parts integrasjoner?

HA vil jo aldri kunne benytte seg av en hash nøkkel som oppdateres/endres dynamisk?

Vanskelig å vite. Tipper de ikke ser på HA brukere som hverken en stor mulighet eller trusssel, men at de har beskyttet API'et sitt mer for å unngå at noen begynner å bruke dataene på en mere kreativ måte. 

8 hours ago, nle said:

@Ziggy Men får du en midlertidig API nøkkel som fungerer? Det er vel kun den nye hasha token som fungerer? Og som jeg antar blir gjort i appen lokalt på noe vis? Så lenge vi ikke har den, vil vi være avhengig av å sniffe trafikken "hele tiden" for å få ny key?

Ja til alt. 

/api/v1/authorization-sessions

er åpen og ser ut til å returnere en «global» token som erstattes av en ny etter noen få timer. Api nøkkelen er nok nå en hash av denne token’en og din bruker-id, og må re-beregnes når den rullerende token’en oppdateres.

Hei, her er et morsomt rent YAML-eksempel jeg kom fram til på en sensor som viser billigste Diesel 'D' innenfor en satt radius (dist_limit=10.0 km) fra "deg" 🙂.

Sensoren puttes inn i Restful-integrasjonen fra eksemplet tidlig i tråden.

Quote

    sensor:
    
      - name: "Billigst Nærme Diesel"       
        value_template: >-
          {%  set ns = namespace(cheapest=none, cheapest_d=none)                                        %}
          {%  set dist_limit = 10.0                                                                     %}
          {%  for s in value_json                                                                       %}
          {%    set dist = distance(s.latitude, s.longitude)                                            %}
          {%    set diesel = s.stationDetails | selectattr('type', 'eq', 'D') | first                   %}
          {%    if (dist < dist_limit) and (diesel.price!=0) and (ns.cheapest==none or ns.cheapest_d.price > diesel.price )   %}
          {%       set ns.cheapest = s                                                                  %}
          {%       set ns.cheapest_d = diesel                                                           %}
          {%    endif                                                                                   %}
          {%  endfor                                                                                    %}
          {%  if ns.cheapest != none                                                                    %}
            {{ns.cheapest_d.price}}|{{ns.cheapest.brand }}|{{ns.cheapest.location }}|{{distance(ns.cheapest.latitude, ns.cheapest.longitude)|float|round(1) }}km|ID {{ns.cheapest.id}}
          {% else                                                                                       %}
            Ingen
          {% endif                 

Sensor verdien er foreløpig en streng, med prisen først:

Quote

18.96|Uno-X|Liertoppen Senter, 3420 Lierskogen Buskerud|7.4km|ID 280

Om noen ser hvordan man kunne hatt bare prisen i sensorverdien og resten som attributter ala tidligere eksempler, hadde det vært interessant. Ser ikke ut som json_attributes_path tillater templates...

Hei,

er det noen av dere med MODBUS-tilkobling som har kikket på flowsettings vs. effekttrekk på viftene ?

Jeg gjorde en liten kjapp enkel test på mitt 2013 VR700 (EC2, Appl  3.05.03) anlegg og fikk noen  interessante resultater.

Satt viftehastighet til høy (REG_FAN_SPEED_LEVEL(101)=3), og brukte REG_FAN_EF_FLOW_HIGH(107) til å styre flow. Setting her gir hos meg auto-oppdatering av leseregisteret REG_FAN_SF_FLOW_HIGH(106) til ca +4%.

Så målte jeg powertekk på hele aggregatet etter ca 20 sek for ulike flowsettings, manuelt med en Deltaco plugg.

De uthevede linjene er settingene som er innstillinger for lav, nominal og høy som ble satt av installatør.
 

E fan l/s = Extract fan flow l/s
S fan l/s = Supply fan flow l/s
S/E       = Forhold mellom supply og extract flow, automatisk satt.
pwm E 	  = resulterende PWM Extract fan (ser ut som fast mapping )
pwm S 	  = resulterende PWM upply fan (ser ut som fast mapping)
EF/SF 	  = omtrentlig Extract/Supply fan RPM (hopper litt opp og ned, opp i max 
			ca 3000rpm, regner med sensorjodling, ser ingen forskjell f.o.m PWM 4,5)
Power 	  = målt powertrekk.
P/pwmS 	  = forhold mellom power og pwm S

Som det fremgår er det ikke mulig å få viftene til å trekke mer power enn 350W tilsammen, selvom  hver av viftene på dette anlegget er spesifisert til 246W.

Noen her i forumet som har gjort tilsvarende observasjoner eller vet mer om temaet?

Er det fysisk mulig at aggregatet kan pumpe dobbelt så mye luft mellom norminal og høy med helt minimal effektøkning og ikke målbar hastighetsøkning? Har dette noe med økt trykk ved økt hastighet, og optimalisert arbeidsområde for viftene og gjøre?

Hvordan er anleggene deres, har dere merkbar el. målbar hastighetsendring på viftene mellom Nominal og Høy setting?

Dere som styrer flowsettings, har dere merkbare evt målbare endringer i flow i hele innstillingsområdet?

VR400 har vifter på 115W hver, hva er effekttrekket på max speed hos dere med VR400?

Jeg hadde forventet en mere direkte sammenheng mellom PWM, som er i range 2 - 10V og effektforbruk, her taker det på en måte allerede rundt nominal på 4.5V, og jeg hadde forventet et effektrekk på ~500W på max flow.

Da har jeg vært oppe en stund med villavent-bridge integrert mot HA, takk for all hjelp @gskjold, dette ser veldig bra ut, kudos for bra jobb! 👍

Oppkoblingen elektrisk er som over og jeg henger på RJ45-kontakten midt på hovedkortet. Repeterer:

• VR700DCV installert 2013.
• Hovedkort EC2 v1.0.0 04.06.2010, FW app EC 3.05.0 [EC boot 1.02.00, CD appl 2.00.32/boot 1.00.02]

Hadde først en runde med Elfin EW11, gjorde en ganske full integrasjon med Modbus/TCP mot HA, og så at det fungerte fint.  

Ser imidlertid løsningen med en MQTT device i nærheten av aggregatet som en bedre vei å gå da det kan generere mye mindre trafikk oppover i systemet. HA slipper å polle registre som aldri endrer seg, og MQTT sensorintegrasjonen er litt bedre i HA.

Tror @gskjold's latest and greatest funker fint, ellers ligger (nesten alt) det jeg kjører foreløpig  på https://github.com/sigvind/villavent-bridge-svi/tree/try-register-manager, koden er en god del mere verbos på serial output som viser hvordan det går med hver enkelt MODBUS-lesing. 

andreash skrev (1 time siden):

Har du koblet A og B på RJ45 uttaget med?

Litt usikker på om jeg oppfatter hva du spør om her, men ja, koblet meg på RJ45-pluggen midt på hovedkortet. Klippet av en cat5 kabel og koblet 3 ledere mot denne fra Elfin:

Det betyr vel at jeg har koblet pin 4 til B og 5 til A, iht til SystemAir dokken under,  mens pin 1 GND gikk til - (minus)

Da jeg hadde byttet om A og B kom det forresten også noe data da jeg brukte RFU, med de gav lite mening, ble mye enere og lite nullere. 🙂

andreash skrev (22 timer siden):

Har lit problem at få igång min HF2211 med Home Assistant mot en VSR300 med EC4.

 

Satte du A -> A och B -> B?

Virkede ikke uden GND og satte du den på skruven som finns på siden av skalet?

Vilka settings har du HF2211?

Vilka settings har du i Home Assistant?

 

 

Mener bestemt at jeg endte opp med A->A / B->B, min blingsing var altså å koble feil i første forsøk.

Prøvde aldri å koble av GND igjen etter å først å koble den, for så å bytte parene. Var såpass i Eureka-humør da det så ut til å fungere at jeg gikk umiddelbart over i ikke-rør-modus.

Jeg kjører en Elfin EW11, den ser litt anderledes ut, men koblet GND-pinnen fra modbus-connectoren på aggregatet til jord på power, som jeg antar blir det samme som GND på HF2211.

Kjører foreløpig 9600,8,1, Even Parity, som var det aggregatet var innstilt på i Modbus-menyen.

Flow Control = Disabled

Protocol = Modbus.

Den siste påvirker innpakkingen/forventet innpakking på TCP, uten å velge 'Modbus' blir det  RFU over TCP ser det ut til.

"IOT Device Series Software Function" manualen refererer til en pakke (Industry products application manual_20200417.zip) som inneholder Modbus Poll. Jeg fant det veldig nyttig å ha en enklere tool å teste enkeltaksesser med for å finne ut hvilke/om registere som svarte og med hva, og samholde med registerdokumentasjonen fra SystemAir. I toolen må du også velge Modbus over TCP hhv RFU over TCP avhengig av hva du har satt i adapteret.

I home Assistant ser det sånn i i headeren:

################################################################################
# Modbus on Elfin EW11 on ventilation
################################################################################
modbus:
  - name:     systemair
    type:     tcp
    host:     192.168.0.223
    port:     8888
    delay:    5     # Startup delay
    sensors:
    
      # FAN CONTROL REGISTERS
      - name:                 "SA valgt viftehastighet"
        slave:                1
        address:              100
        input_type:           holding   # 0=off, 1=low, 2=normal, 3=high, 4=auto
        scan_interval:        5
        data_type:            uint16

PS: mitt aggregat støtter ikke auto på viftehastighet.

Håper dette tar deg videre!

sinamics skrev (På 6.4.2022 den 10.44):

Jepp, ser likt ut. 
Jeg prøvde den pluggen på hovedkortet, samt den pluggen som sitter i toppen av aggregatet som er beregnet for remote kommunikasjon, men fikk ikke noe data.

@sinamics, se 

vet jo ikke om VR400 serien opererer med samme FW versjonsserie, i.e om det er samme kort/FW, men jeg øyner jo håp for mitt 2013 VR700 med EC2 og denne EW11 altså. Har ESP32 og RS485 moduler i transitt, mulig jeg kommer til å teste ut @gskjold sin kode her også, avhenger av hvor deployed løsningen med EW11 blir før jeg får dem. 🙂

Sigarene rulles i øyeblikket ut, har noe ut via Modbus Poll som gir mening. 

Hadde blingsa på A+ og B-. Byttet, og koblet også GND  (pinne 1 fra Rj45 på aggregatet) til jord fra power på EW11.

Dette er altså et VR700 anlegg, med firmware EC appl 3.05.03 boot 1.02.00 / CD appl 2.00.32 boot 1.00.02, vet ikke om det er samme kort og FW som på VR400, men noterer for the record, i.e. for andre.

Noterer også noe som var litt forvirrende med modbus poll programmet. For å få verdien av register 101 fra SystemAir MODBUS registerspekk, må man oppgi registerverdi 100, tror det er noe som er avledet av MODBUS spekken.

TomB skrev (13 timer siden):

 

Hei.

Det første du gjør er å få adapteret opp på Wifi og endre passord, evnt IP osv. Da er du klar til å sette inn kabelen i Modbus porten. Husk å sjekke serial settings på aggregatet, min var 19200, 8, 1, N om jeg husker rett, du må bare sette Elfin adapteret i samme modus som aggregatet står på.

 

Modbus fungerer sånn at du ikke får noe data på porten før du faktisk forespør det, så jeg tror ikke du vil se noe særlig der før du faktisk begynner å sende kommandoer.

 

Jeg reiser på 3 ukers ferie i morgen så jeg får ikke hjulpet deg noe før jeg er tilbake, men da kan jeg absolutt gi deg noen tips og scripts for å få deg i gang.

Jepp, det snurrer på TCP, men kan visst ikke røke noen sigarer ennå 🙂

Hva satt du 'Flow Control' og 'Protocol' til @TomB? Kan velge flow control 'Disable', 'Flow Control' og 'Half Duplex', SystemAir sier ingenting om dette i modbus-dokkene, vet ikke om det er relevante settinger her. Protocol gir valgene 'Modbus', 'Frame' og 'none'. Har ikke funnet noen comboer som gir fornuftige resultater foreløpig. Prøver meg med "Modbus Poll", her forsøker jeg å hente register 1F5 med en read input register, burde returnert verdien 1 for VR700 🙂

Tx:005900 - 01 04 01 F5 00 01 20 04
Rx:005901 - 7F 9F 2A FF FD 73
 

@TomB, fått inn Elfin EW11 og forbereder påkobling. Blir ikke tid til å teste det før om noen dager, men har du noen kjappe innledende tips til settings på adapteret?

Så det var et modbus av/på protokollvalg, antar den må slås på f.ex? Brukte du default UART settings fra displayet på aggregatet?

Vet du om noen lavterskel måte å teste at det faktisk kommer svar fra aggregatet uten å koble inn hele shebangen med HA etc? Ute etter et enklere verktøy der jeg kan taste inn et modus-register som er sannsynlig at skal svare, for å se om noe kommer tilbake... 🙂

Takk @gskjold, jeg skal prøve med en Elfin EW11 først, som blir bekreftet at ihf fungerer mot @TomB’s vr400 med ec4 og ny fw. Det reduserer antall ukjente og kan kanskje avdekke om mitt 2013 vr700 med ec2 faktisk kan snakke modbus-språket såpass at det er mulig å bruke. Lever i håpet. 🙂

Må uansett legge noen sånne ESP moduler inkl den RS485 modulen i bestilling så jeg kan lære litt - takk for tips, er mange varianter ser det ut til. Vil en wemos D1 mini også kunne gjøre jobben her?

Takk for jobb på AMS, skal sjekke status på prosjektet!

@TomB, Elfin i bestilling, tar en måneds tid før det dukker opp 🙂 Blir moro å se.

Kult. Så separat power adapter med to tråder inn på Elfin'en?

OK, takk for link.

Betyr dette at du bruker serielkommunikasjon (via TCP) helt inn i din HomeSeer?

Jeg bruker HomeAssistant, men ser det skal være TCP/modbus-støtte der også muligens.

Fint å vite at Elfin-EW11 er brukbar tilformålet ihf, den ser jo lett ut å koble opp.

Hei @gskjold, jeg kunne gjerne tenke meg å prøve ut ditt prosjekt på mitt anlegg og bidra med feed-back.

Hva er status på prosjektet i øyeblikket, har dere noe som er ganske stabilt dere som kjører dette?

Har ikke noe erfaring med å koble opp ESP-moduler så langt, men har ønsket å prøve det ut på noe. Er det f.eks noen måte å verifisere koblinger av RS485-delen før jeg kobler til anlegget, så jeg kunne redusert antall ukjente, eller hva anbefales for en novice?

Er det essensielt å få tak i eksakt samme HW her for å forenkle ting, eller er disse ESP-modulene med wifi same-same alle sammen? Et par pointere til spesifikke deler, evt med basic koblingsskjema, kunne nok være til hjelp for å komme igang.

Utgangspunktet mitt er "to tomme hender", relativt god programmeringskunnskap, og et

• VR700DCV installert 2013.
• Hovedkort EC2, FW app EC 3.05.0 [EC boot 1.02.00, CD appl 2.00.32/boot 1.00.02]
• En uttalelse fra en rep hos leverandør at dette kortet med denne FW'en skal kunne kjøre Modbus.

Jeg har også en AMS-reader og vet overordnet hvordan den virker, og ser at tilsvarende funksjonalitet for ventilasjonsanlegget vil være et kult tilslag.

Hovedkortet ser forøvrig slik ut, så det er ihf tenkt på Modbus, @sinamics, ligner dette på ditt som du ikke fikk til å fungere?

 https://www.hjemmeautomasjon.no/uploads/monthly_2022_04/hovedkort_ec2_redux.jpg.8ad97ed1e1994172cf8fd6595a426616.jpg

Takk for svar @TomB.

Modbus-menyen er der, kortet er EC2, EC Appl ver 3.05.03... og til alt overmål fikk jeg også en uttalelse fra en teknisk representant for leverandør at 3.05.03 på dette anlegget skal kunne kjøre Modbus.

Dette bringer jo veldig forsiktig håp, og lyst til å prøve seg. Kan jo være at nødvendig FW versjon ikke er 5.xx på dette anlegget slik det virker som har vært konklusjonen i noen tråder her.

Slik ser hovedkortet ut, ligner det på det som står i deres anlegg?

Melder meg på i 

@TomB kan man tolke dette til at SystemAir mener modbus bør virke for de som har EC2 og nyere? Har en vr700dcv produsert i Jan 2013 og lurer på å prøve. Vet du om man se på anlegget hvilken rev av kort man har? Ut fra delelister kan det se ut som noe skjedde i slutten av 2012 på dette. 

Til info for andre: Får napp på OOK modulasjon med Manchesterkoding på mine slike sensorer. De sender id, (20 bit som står på en etikett på den største chippen på PCB-en), temperatur (9 bit temp i tideler) og innstilt temperatur (samme) samt det som trolig er en kommando på/av. 
Jeg bruker en RTL-SDR dongel til det her. Ta evt kontakt for flexdekoder oppsett. Ser ut til å være litt støyproblemer foreløpig og har problemer men noen av sensorene. 

Der er nok ikke noe toveiskommunikasjon on ingen kryptering. Tror jeg har reverse engineeret én byte sjekksum/crc til å være Reverse Galois byte reflect med polymom 0xd6 (etter hukommelsen) og key 1, sluttverdi 0x30. 
Leker videre med det her.

Hei TomasBK, kom du i mål på denne? Har en slik WFHC enhet selv som jeg har lyst til å snakke med.