Säg inte det, när klockan är 24 (efter omställning), och något tror att den är 24 och något annat tror att den är 23 är det väl absolut möjligt att det blir knas i timme 22-23.D Dublin skrev:
Hade det varit timme 17 eller 09 eller nåt hade jag varit mer benägen att bara slå bort den tanken.
Hm, problemet är att rådatan från min entity (från tibber pulse) är korrekt, men summeringen som HA gör och som visas i Energy dashboarden är fel. Alltså måste justeringen göras i db där värdena lagrats, frågan är bara hur jag kommer åt den?K KentaBro skrev:
Jo det är ju sant. Men då borde jag inte vara ensam om detta. Nån annan som kopplat indata från Tibber pulse till energy dashboarden och kan verifiera att den har samma problem?tveksamt skrev:
Jag har inte just det problemet, men jag hämtar data (spotpriset) via Tibbers API och där blev det pannkaka under ett och ett halvt dygn.
Scriptet kukade ur när söndagens priser släpptes och återhämtade sig när det blev måndag.
Så att Tibber hade strul vågar jag mig på att säga, om det är just det som påverkat dig kan jag inte bekräfta.
Scriptet kukade ur när söndagens priser släpptes och återhämtade sig när det blev måndag.
Så att Tibber hade strul vågar jag mig på att säga, om det är just det som påverkat dig kan jag inte bekräfta.
Är det någon här som har erfarenhet av att bygga egna integrationer, direkt i HA?
Har knåpat ihop en enkel direktintegration med Husdatas gamla gränssnitt som pratar seriellt/rs232, men kör fast lite på att enheten inte har något som helst unikt ID (inget serienummer, MAC-adress eller liknande). Dokumentationen är väldigt tydlig med att det inte är acceptabelt att använda namnet på serieporten, vilket i brist på annat är lite lockande.
Har knåpat ihop en enkel direktintegration med Husdatas gamla gränssnitt som pratar seriellt/rs232, men kör fast lite på att enheten inte har något som helst unikt ID (inget serienummer, MAC-adress eller liknande). Dokumentationen är väldigt tydlig med att det inte är acceptabelt att använda namnet på serieporten, vilket i brist på annat är lite lockande.
Har ingen egen erfarenhet med att "knåda kod" men du har massvis med projekt i Github.C cpalm skrev:
https://github.com/
Sök med olika relevanta sökord för dig så kanske det finns något.
Exempel "RS232"
https://github.com/search?q=rs232
Ja, tibberintegrationen är ett elände. På GitHub verkar det som att problemet är att det finns ett antal HA-användare som kör väldigt gamla versioner och det river ner deras API och det verkar inte hjälpa hur mycket de än bygger ut. Och på HA-sidan kommer det ständigt nya uppdateringar som försöker lösa problemet. Men om användarna ligger kvar på gamla versioner, hjälper ju inte det...
//Fumble
Tack för tipset. Jorå, inte minst alla befintliga integrationer i HA är en rik källa med exempel. Har så klart rotat runt där, men har inte hittat något där inte enheten kan spotta ut sig ett serienummer eller liknande unikt ID. Åtminstone inte något som jag begriper mig på.P paralun skrev:
Ifall du använder en USB<->RS232 adapter så skulle du ju kunna ta serienummret från USB enheten, där krävs ju unika serienummer. Annars går det nog inte om det inte finns s.a.s. Då får man väl gå på backuplösningen: https://developers.home-assistant.io/docs/entity_registry_index/#unique-id-of-last-resortD Dublin skrev:
Tack för svar!J Jensa86 skrev:
Får väl börja med att understryka att målet är att få till något som kan accepteras som en officiell integration. För min egen skull kan jag lika gärna hårdkoda det unika id:t till 1234 eller nåt, då jag i praktiken bara kommer att ha en enhet och kan strunta i de officiella riktlinjerna.
Det har slagit mig som ett alternativ att använda det unika USB-ID:t från adaptern, som, åtminstone indirekt, går att få ut från pyserial som jag använder för att prata RS232. Dock är det ju i ett generiskt scenario inte nödvändigtvis en USB->RS232-adapter. Det resonemanget för mig till att jag i princip då skulle kunna använda portnamnet (t.ex. "/dev/ttyS0") i så fall, vilket dock som sagt är uttryckligen "förbjudet".
Jag har läst detta med "Unique ID of last resort", men kruxet där är att det gäller "For entities that are setup by a config entry". Vilket jag tolkar som en enhet som manuellt definieras i configuration.yaml(?) Till skillnad mot enheter som läggs upp via webgränssnittet och integrationens config_flow (vilket är en "finess" som i princip förväntas idag antar jag).
Dvs. det jag i princip är ute efter är motsvarande "Unique ID of last resort" för enheter som sätts upp genom webgränssnittet. Men här kommer vi väl till pudelns kärna, vilket är att jag inte har en tillräcklig djup förståelse för det unika ID:ts funktion i HA
Syftet med unika ID't är väl att devicen ska vara densamma oavsett om man byter namn, byter USB-port, etc? Och att lika dana enheter inte ska krocka med varandra.
Kan du inte skapa ett ID baserat på en random unik sträng för ditt projekt och lägga på serieportens löpnummer?
Kan du inte skapa ett ID baserat på en random unik sträng för ditt projekt och lägga på serieportens löpnummer?
Jo med hjälp av en hederlig terminal så ser du nog exakt vad det är och kan leta vidare bland alla projekt.C cpalm skrev:
Sen har du också sk HACS projekt som ligger vid sidan av ordinarie HA men i princip alla integrationer har sitt ursprung i Github.
Översikt av USB anslutna prylar
lsb
Sen detaljerna ser man mha
udevadm info -r -q all /dev/ttyUSB0
Då får man upp alla detaljer
Jag tror inte ID:t behöver vara unikt mellan olika integrationer, så någon random sträng behövs nog inte.useless skrev:
Det man tappar med att använda serieportens löpnummer/namn är man förlorar alla inställningar och kopplingen till dashboards, automationer, m.fl. objekt om man flyttar enheten till en annan port. Det är väl därför riktlinjen säger att det inte är acceptabelt antar jag.
I enlighet med "Unique ID of last resort" är kanske det bästa av de "icke-acceptabla" alternativen att låta användaren skriva in ett eget ID helt enkelt(?)
Kanske får ställa frågan på HA:s utvecklarforum...
Jag räknar med att att man får använda "Unique ID of last resort" även om man inte strikt har manuell konfigurering i yaml. Är nog bara inte uppdaterat på länge och det var "så man gjorde" förut. Det är inte något serienummer på Husdata enheten eller så man kan be om att manuellt mata in?
