Autor Thema: [erledigt] SVG problem: gplot file marked as readonly: won't write!  (Gelesen 2411 mal)

Offline the ratman

  • Hero Member
  • *****
  • Beiträge: 2927
  • cosmoprolet & intelligenzdiabetiker
    • der ratti auf mastodon
hiho,

nach längerer zeit, wollt ich wieder mal einen plot anlegen, also:
"define plot_spritpreise SVG logdb:plot_spritpreise:HISTORY"

das svg wird angelegt, ich kann aber im svg (außer bei den attributes) nirgendwo was eintragen und drücke ich auf "write .gplot" schreibt er die freundliche meldung aus der überschrift raus.

o) das gplot-verzeichnis hab ich mittlerweile auf 777, mit dem user "fhem" als eigentümer
o) drücke ich bei einem vorhandenen plot auf "write .gplot" macht er dies anstandslos

hat sich irgendwas verändert, dass ich verpennt hab, oder was rennt hier falsch?
« Letzte Änderung: 18 Mai 2022, 12:17:34 von the ratman »
→do↑p!dnʇs↓shit←

Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 12726
  • NIVEAu ist keine Creme...
Antw:SVG problem: gplot file marked as readonly: won't write!
« Antwort #1 am: 18 Mai 2022, 12:06:11 »
https://forum.fhem.de/index.php/topic,126561.msg1211685.html#msg1211685

EDIT:
Zitat
o) das gplot-verzeichnis hab ich mittlerweile auf 777, mit dem user "fhem" als eigentümer
warum immer gleich Rechte aufbohren ;)

Gruß, Joachim
« Letzte Änderung: 18 Mai 2022, 12:09:38 von MadMax-FHEM »
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Offline the ratman

  • Hero Member
  • *****
  • Beiträge: 2927
  • cosmoprolet & intelligenzdiabetiker
    • der ratti auf mastodon
Antw:SVG problem: gplot file marked as readonly: won't write!
« Antwort #2 am: 18 Mai 2022, 12:17:23 »
einfach nur zur sicherheit beim testen. nicht, dass es an den rechten scheitert *g*

danke dir für den hinweis - jetzt geht's.

anm.:
wie ich das hasse, wenn man mal 5 min in fhem nicht aufpasst und irgendwer irgendwas verdreht.
manches mal hab ich den eindruck, dass machen die leuts nur, um die noobs zu ärgern *g*
→do↑p!dnʇs↓shit←

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 25832
Antw:SVG problem: gplot file marked as readonly: won't write!
« Antwort #3 am: 18 Mai 2022, 12:31:53 »
Zitat
wie ich das hasse, wenn man mal 5 min in fhem nicht aufpasst und irgendwer irgendwas verdreht.
Und ich frage mich, warum die Leute dauernd FHEM-updates machen, wenn sie keine Aenderungen wollen. :)

Offline the ratman

  • Hero Member
  • *****
  • Beiträge: 2927
  • cosmoprolet & intelligenzdiabetiker
    • der ratti auf mastodon
ich hab nix gegen änderungen, nur probleme, wenn ich nix von weiß und dann wie n dödel da stehe.

frage:

irgendwie wärs wohl mal überlegenswert, wenn man eine "update" info in fhem hätte.
könnte man das nicht automatisiert aus eurem "code changes" entnehmen? z.b. in ein modul.
vielleicht sogar einstellbar mit: "noob-infos", "fortgeschrittenes", oder alle updates für "coder" ...

noob-info: "knöpfchen x macht jetzt y". oder: "da ist eine neue funktion für dich hinzugekommen".
internes gedöns interessiert leute wie mich eh ned, weil wirs sowieso ned verstehen ...

könnte ich mir so richtig schön vorstellen. du machst 'n update, schaust dann in dein logfile, ob eh alles gut gegangen ist und dort steht dann das wichtigste an änderungen für deine module.
oder die "noob-proof" version: nach n update steht ein popup für den dümmsten da, bis man o.k. klickt *g*
« Letzte Änderung: 18 Mai 2022, 13:20:18 von the ratman »
→do↑p!dnʇs↓shit←

Online frank

  • Hero Member
  • *****
  • Beiträge: 11154
Zitat
ich hab nix gegen änderungen, nur probleme, wenn ich nix von weiß und dann wie n dödel da stehe.
was ist mit "update check" vor einem update?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Offline the ratman

  • Hero Member
  • *****
  • Beiträge: 2927
  • cosmoprolet & intelligenzdiabetiker
    • der ratti auf mastodon
ich hab ja kein update-problem gehabt, nur ein info-problem.
was nutzt mir auch ein update-check, wenn die änderung schon 1 monat her und eigentlich ja nicht mal ein fehler ist?

wirfst du dann prof. dr. dr. google an, findest du auch wunderschöne infos zur fehlermeldung. leider nix richtiges, weil du da meist über infos zu user/file-rechte stolperst.
ohne MadMax-FHEM's link würd ich wahrscheinlich jetzt noch nach dem problem suchen.

obige "idee" würde großteils vermeiden.
→do↑p!dnʇs↓shit←

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19364
...irgendwie ist diese Diskussion um "wie als User Info über updates im Voraus erhalten" ein Dauerbrenner...

Habe z.B. das hier gefunden (2012): https://forum.fhem.de/index.php/topic,9085.0.html, aber eigentlich gesucht nach was, wo es fast wortgleich auch Hinweise zu "inform" (?) gab...

Kurzfassung aller Diskussionen, die ich dazu kenne: Die Maintainer müßten was kompliziertes pflegen, und die User müßten das dann auch lesen. Vermutlich ist in CHANGED der erste Teil sogar meistens (!) noch gut abgedeckt, wenn auch in vereinfachter Form...

Vielleicht wäre die Summe der Änderungen seit 6.1 ausreichend, um 6.2 zu "veröffentlichen"? (V.a. in Homematic-Bereich (alle Module) scheint es soweit ruhig zu sein...). Dann hat der updategeeigte User zumindest einen "Anhaltpunkt", dass er sich mal umsieht, was ggf. passiert ist ::) .
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Offline the ratman

  • Hero Member
  • *****
  • Beiträge: 2927
  • cosmoprolet & intelligenzdiabetiker
    • der ratti auf mastodon
tjo, der user ists halt gewohnt, seine infos in schönen, verständlichen häppchen zu kriegen, oder a'la google-android "wir haben etwas verbessert, um ihr nutzererlebnis weiter zu trüben" *g*

aber im ernst - eigentlich stünde ja schon alles hier im forum in den "code changes"
das müsste ja "nur" gefiltert werden, weil alles eh keiner lesen und verstehen würde ... also ich.

ich weiß, ich hab leicht reden .. aber ihr habt's immer gute ideen. ich wart mal ab, dann schleicht sich sicher wieder irgend ne geile lösung von euch durchs hintertürchen.
→do↑p!dnʇs↓shit←

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19364
das müsste ja "nur" gefiltert werden, weil alles eh keiner lesen und verstehen würde ... also ich.
Na ja, die "messages", die der jeweilige Maintainer beim Einchecken von Änderungen mitgibt, sind mal mehr, mal weniger aufschlussreich, und wie "gefährlich" was ist, kann man m.E. nicht mit vertretbarem Aufwand automatisiert ermitteln (zumal das ggf. auch noch subjektiv (aus Usersicht ) gefärbt ist).
Also gibt es keinen wirklich besseren Weg, als diese Verantwortung dem jeweiligen Maintainer zu übergeben - und der schreibt halt ggf. was in CHANGED (bzw. UPGRADE) rein, oder eben nicht. (oder - so entsprechende Optionen vorhanden wären - er würde bestimmte "flags" beim Einckecken setzen oder eben nicht...)

Zitat
ich weiß, ich hab leicht reden .. aber ihr habt's immer gute ideen. ich wart mal ab, dann schleicht sich sicher wieder irgend ne geile lösung von euch durchs hintertürchen.
Wie angedeutet ist das die vergangenen 10 Jahre (+?) immer wieder ein Thema gewesen, und ich glaube ehrlich gesagt nicht, dass da jemand "plötzlich" eine zündende bessere Idee hat. Wenn, dann müßte "jemand" im Nachgang zu irgendwelchen Änderungen einen review machen und festlegen, ob die jeweilige Änderung (bzw. ein Entwicklungsschritt, der mehrere umfasst) "bekannt" gemacht werden sollten (oder sonstwie klassifiziert). Das ist aber eine Heidenarbeit und mit subjektiven Elementen gespickt. Nun ja, ...
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Offline the ratman

  • Hero Member
  • *****
  • Beiträge: 2927
  • cosmoprolet & intelligenzdiabetiker
    • der ratti auf mastodon
versteh's eh. aber man muss euch ja auch ein bissi fordern, sonst wird euch ja noch langweilig *g*
ein argument hab ich für die maintainer aber: je besser der dau geführt wird, je weniger nervt er.
→do↑p!dnʇs↓shit←

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19364
ein argument hab ich für die maintainer aber: je besser der dau geführt wird, je weniger nervt er.
Aha...

Mein Eindruck ist eher: Je besser er geführt ist, desto weniger denkt er selbst nach, und desto seltsamere Dinge passieren...

(Die hier diskutierte Änderung ist jedenfalls mAn. sehr sinnvoll gewesen, weil sie versehentliche Manipulationen an den zentral verteilten .gplot verhindert und daher eher alle auf einem Stand sind...).
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Offline the ratman

  • Hero Member
  • *****
  • Beiträge: 2927
  • cosmoprolet & intelligenzdiabetiker
    • der ratti auf mastodon
ich zweifle auch nicht an sinnhaftigkeiten. dafür haben wir euch ja, damit fhem immer sinnvoller wird ...

ich zweifle (denke, da haben sogar wir 2 schon mal geredet drüber), an der grundlegenden kommunikation zwischen programmierer und anwender. der ein fühlt sich angegriffen, weil der andere nicht versteht was gemeint ist. keiner meints böse, aber ... und da für eine schnittstelle zu sorgen wäre traumhaft.
→do↑p!dnʇs↓shit←