HenFre skrev:Jag har lite info att sprida när det gäller RFXtrx433e och NEXA.
Jag använder lite NEXA prylar på ställen som jag inte tycker är så viktiga att det fungerar perfekt. Trots det tycker jag att jag fått det att fungera perfekt efter de behov jag har.
Som controler till 433 MHZ använder jag RFXtrx433e kopplad via USB till RPIn.
[bild]
Nexaprylarna jag har är:
6 st. EYCR-2300/250 mottagare
2 st. LYCT-705 sändare
[bild]
Det som är lite trixigt att installera är RFXtrx433e modulen. Den ska uppgraderas med senaste programvaran. Men när det har gjorts så fungerar det perfekt.
Ingen installation av enheter behöver göras utan RFXtrx433e lyssnar och skapar de enheter den "hör". Det innebär dessvärre att den även inkluderar grannarnas enheter om signalen "hörs".Det gäller alltså att strikt begränsa sig till de protokoll man använder själv för att inte få in för många okända enheter. Men visst kan det bli så att grannens regnmätare kan få serva mig också!
Det var bara att trycka på fjärrkontrollernas knappar så var allt installerat. Sedan bara att namna upp.
Man får en switch per knapprad på kontrollen. Varje kontroll ger alltså 4 st. lampswitchar och en gruppswitch.
[bild]
Det luriga är gruppswitchen. Den tänder alla kopplade lampor utan att deras motsvarande switchar får status ON. Enbart "Gruppswitchen" får status ON när den används. Men frågar man på status är inte svaret "On/Off" utan "Group On/Group Off". Däremot om man klickar på gruppswitchen på skärmen så är det statusen "On/Off" som lagras på switchen. Därför måste alla LUA-skript som triggas av gruppswitchen hantera båda fallen.
Gruppknappen på fjärrkontrollen tänder/släcker lampor vars switchar visar motsatt status mot vad som är verkligheten.
Jag har löst detta med två LUA-skript. Ett per fjärrkontroll. Här är det ena:
[bild]
Skriptet ger alla ingående switchar rätt status efter att gruppknappen använts.
//Henry
Ett litet tips till:
Eftersom det är kontrollen till 433 MHz utrustningen som skapar devices i Domoticz när man använder RFXtrx433e så kan man använda NEXAs fjärrkontroll "NEYCT-705" som fjärrkontroll till Z-Wave systemet. Det är bara att trigga LUA-skript med 433 MHz-kontrollerna som uppstår i Domoticz.
Därmed så kan man skaffa fjärrkontroller som hanterar upp till 16 Z-Wave devices per kontroll för endast 129:-- Kr hos Clas Ohlsson
http://www.clasohlson.com/se/Fjärrkontroll-Nexa-LYCT-705/36-4612
eller 94:-- Kr hos NetOnNet.
https://www.netonnet.se/art/hemhush.../hemautomatisering/nexa-lyct-705/183091.9436/.
//Henry
Nädå, jag kopierar från WindowsHenFre skrev:När jag installerade DzVents gjorde jag jobbet i RPIn. Hade inte kopplat upp då med Samba.
Är det något som hindrar att man laddar ner och packar upp i Windows och kopierar över till RPIn därifrån? Enklare att hantera än när man måste slå upp vart enda kommando.
//Henry
Hahahaha, ja fy fasen. Med minimala förkunskaper inom Java och Assembler, (jag menar verkligen minimala), så var inte det här en barnlek direkt.
Vad jag vill åstadkomma är följande:
Effektmätande Qubinoplugg där effektmätaren heter P TV-Ö
Rullgardinsmotor som heter Rullgardin TV
När effekten kliver upp i Qubinopucken som TV:n är ansluten mot så skall rullgardinen gå ner. Detta är egentligen enkelt att få till med Blockly, men det har visat sig lite buggigt. Ibland registrerar pucken en snabb höjning av effekten trots att TV:n är avstängd. Detta har resulterat i att rullgardinen går ned trots att TV:n är avstängd.
Vidare till min DzVents-kod. Tanken är att jag ska läsa av snittförbrukningen under 3 minuter, och baserat på resultatet höja eller sänka rullgardinen. Synpunkter på koden innan jag bemödar mig med att lägga över det på Raspberryn?
return {
active = true,
on = {
['timer'] = 'every minute'
},
data = {
readingHistory = { history = true, maxItems = 3 },
}
execute = function(domoticz)
local consumption = domoticz.devices['P TV-Ö'].WActual
domoticz.data.readingHistory(consumption)
local average = domoticz.data.readingHistory.avg
if (average >=35) then
domoticz.devices['Rullgardin TV']dimTo(100)
elseif (average <=10) then
domoticz.devices['rullgardin TV']dimTo(0)
end
end
}
Vad jag vill åstadkomma är följande:
Effektmätande Qubinoplugg där effektmätaren heter P TV-Ö
Rullgardinsmotor som heter Rullgardin TV
När effekten kliver upp i Qubinopucken som TV:n är ansluten mot så skall rullgardinen gå ner. Detta är egentligen enkelt att få till med Blockly, men det har visat sig lite buggigt. Ibland registrerar pucken en snabb höjning av effekten trots att TV:n är avstängd. Detta har resulterat i att rullgardinen går ned trots att TV:n är avstängd.
Vidare till min DzVents-kod. Tanken är att jag ska läsa av snittförbrukningen under 3 minuter, och baserat på resultatet höja eller sänka rullgardinen. Synpunkter på koden innan jag bemödar mig med att lägga över det på Raspberryn?
return {
active = true,
on = {
['timer'] = 'every minute'
},
data = {
readingHistory = { history = true, maxItems = 3 },
}
execute = function(domoticz)
local consumption = domoticz.devices['P TV-Ö'].WActual
domoticz.data.readingHistory(consumption)
local average = domoticz.data.readingHistory.avg
if (average >=35) then
domoticz.devices['Rullgardin TV']dimTo(100)
elseif (average <=10) then
domoticz.devices['rullgardin TV']dimTo(0)
end
end
}
Är du säker på att det är bugg i Blocky som är orsaken? Hur ofta och på vilka differenser rapporterar din puck?Flugbuljong skrev:
Personligen avstår jag från rutiner som använder historiken. Tycker jag har för dålig koll på varifrån och hur det hämtas. SD-kortet är det långsammaste du har i din RPI. System har en tendens att växa och så småningom skapar för många läsningar/skrivningar till SD-kortet en slö RPI. Jag har redan problem med detta då och då. Har gissat att det har med skrivning av historik till SD-kortet att göra.
Såhär skulle jag lösa uppdraget:
Lycka till!
//Henry
Redigerat:
Fantastiskt HenFre, du är grym!
Jag använde nog termen buggigt lite felaktigt, det är snarare pucken eller Domoticz som är buggigt i det här avseendet. Jag gick igenom loggen på P TV-Ö och såg att jag hade en ganska kraftig peak som motsvarar produktionen i en medelstor vindkraftpark, 56,6MW...
Kanske kan man ändra rad 12 enligt följande för att förhindra ett skyhögt medelvärde:
if ( domoticz.devices['P TV-Ö'].lastUpdate.secondsAgo <= 60 and domoticz.devices['P TV-Ö'] <=300)
Normalt ska förbrukningen ligga på ~3-5W i standby, och någonstans mellan ~100-250W med TV:n påslagen. Antar man att TV:n skulle dra 100W under första minuten så borde ett medelvärde ~35 innebära att rullgardinen går ner efter en minut. Borde kanske ändra så att medelvärdet ska ligga i området >2/3 av 100W för att förhindra att en enstaka felrapportering hissar ner gardinen. Visserligen innebär detta att man får vänta i två minuter, men det kan jag leva med.
Kommer inte ihåg med vilken frekvens jag har ställt in effektrapporteringen på, men jag tror att det är 300 sekunder och/eller 10% förändring.
Jag använde nog termen buggigt lite felaktigt, det är snarare pucken eller Domoticz som är buggigt i det här avseendet. Jag gick igenom loggen på P TV-Ö och såg att jag hade en ganska kraftig peak som motsvarar produktionen i en medelstor vindkraftpark, 56,6MW...
Kanske kan man ändra rad 12 enligt följande för att förhindra ett skyhögt medelvärde:
if ( domoticz.devices['P TV-Ö'].lastUpdate.secondsAgo <= 60 and domoticz.devices['P TV-Ö'] <=300)
Normalt ska förbrukningen ligga på ~3-5W i standby, och någonstans mellan ~100-250W med TV:n påslagen. Antar man att TV:n skulle dra 100W under första minuten så borde ett medelvärde ~35 innebära att rullgardinen går ner efter en minut. Borde kanske ändra så att medelvärdet ska ligga i området >2/3 av 100W för att förhindra att en enstaka felrapportering hissar ner gardinen. Visserligen innebär detta att man får vänta i två minuter, men det kan jag leva med.
Kommer inte ihåg med vilken frekvens jag har ställt in effektrapporteringen på, men jag tror att det är 300 sekunder och/eller 10% förändring.
Det är möjligt att du har rätt och att jag tänkte fel. Ovan vid LUA-tänk?dhanjel skrev:
Tänkte mig variabler som globala minnesvariabler men de behåller ju sitt värde mellan omstarter så de skrivs naturligtvis till SD-kortet. Då är det bara frågan vilket som går fortast. Hur utsökning av "historik" går till och det vet inte jag. Har bara lagt märke till att RPIn kan få mycket långa svarstider ibland utan att det lämnar spår i processorhistoriken. Jag har tolkat det som att SD-kortet sinkar ibland.
Tillägg:
Kan man skapa någon sorts globala minnesvariabler som har räckvidd mellan LUA-skripten men som inte skrivs till kortet. Det är ju rätt användbart för programkontroll.
//Henry
Redigerat:
Ja så kan det vara, nackdelen med "vanliga" variabler utanför dzVents som jag ser det är att det rätt lätt blir oöverskådligt med många variabler. Med dz så defineras dom ju mer isolerat i scripten.
Vet faktiskt inte om de har stöd för minnesvariabler på nåt sätt. Tror inte det har det, varje script är ju en egen instans. Går väl alltid göra en egen liten nodejs-server som har det och så gör man anrop till den via http. Men det känns inte så effektivt.
Valde själv att köra på en intel nuc och ssd-disk, just för att slippa tänka på minneskorten.
Gick från en Fibaro HC2, så det blev ändå billigare
Vet faktiskt inte om de har stöd för minnesvariabler på nåt sätt. Tror inte det har det, varje script är ju en egen instans. Går väl alltid göra en egen liten nodejs-server som har det och så gör man anrop till den via http. Men det känns inte så effektivt.
Valde själv att köra på en intel nuc och ssd-disk, just för att slippa tänka på minneskorten.
Gick från en Fibaro HC2, så det blev ändå billigare
Jaha! Så tycker inte jag man kan tolka dokumentationen! Då är ju skillnaden inte stor. Är det så svårt att skapa minnesvariabler med global räckvidd i Rasbian med LUA eller är detta en nackdel man får med DzVents eller är det ett LUA problem?dhanjel skrev:
Då "sliter" man ju ut SD-korten onödigt fort med tiden även om man har ett som är bra på att sprida skrivningarna. Frågan är hur man förstår att ett minneskort gjort sitt när det börjar nå gränsen.
Kanske får gå in för att byta dem med jämna mellanrum. Men SSD lever inte för evigt heller. Hur stor SSD kan du ha i din maskin?
//Henry
Redigerat:
Tror varje script körs isolerat och är bara scope så länge det körs.
Har en 256gb ssd i min. Men kör vmware esxi och ett par servrar på den (nextcloud, pi-hole, Web/mail).
Är man orolig så kan man ju alltid ha en usb sticka med och sen länka dzvents storage mapp till den (vet inte exakt ur man gör, men googla symlinks)
Har en 256gb ssd i min. Men kör vmware esxi och ett par servrar på den (nextcloud, pi-hole, Web/mail).
Är man orolig så kan man ju alltid ha en usb sticka med och sen länka dzvents storage mapp till den (vet inte exakt ur man gör, men googla symlinks)
Nja, backupen bekymrar mig inte. Jag plockar ur SD-kortet, när jag gjort förändringar, och kopierar det som image till min stationära dator. Sedan åker det med i den vanliga backuppen som är 1 ggr/timma till en NAS och därifrån 1ggr/dygn till två andra NASar varav en står på annan ort och kontaktas via fiber. Det är enkelt att skapa ett nytt med senaste versionen.dhanjel skrev:
Det jag funderar på är hur man diagnosticerar att det är SD-kortet som börjar bli svagt?
//Henry
Är det någon mer än jag som ibland får problem med att systemet blir så in i helsikes segt emellanåt? Tidigare idag funkade det helt felfritt, och nu helt plötsligt är systemet helt oanvändbart. Varje manuellt till- och frånslag tar flera minuter att utföra, och ganska ofta resulterar det dessutom i time-out.
