• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

Urwigo: wie speichert man eine Liste von zB Uhrzeiten?

cache7

Geocacher
Hallo,

ich verwende den Urwigo. Für den nächsten Cache hätte ich nun die Idee Events an bestimmte Zeiten zu koppeln. Hat mir jemand eine Tipp wie man die am besten ablegt? Wenn möglich möchte ich diese nicht hardcodiert in den Tiefen des Codes sondern möglichst Liste.

Danke für die Tipps!

cache7
 

TriNitro

Geocacher
Hallo cache7,

ich würde dir wirklich gerne helfen (oder s zumindest versuchen), aber kanst du dein Problem vielleicht noch ein bisschen konkreter beschreiben? So ganz verstehe ich das bisher leider nicht... :eek:ps:

Willst du einfach nach einer bestimmten Zeit ein Event starten (einfach über Timer, OnElapsed) oder geht es dir mehr um eine vereinfachte Eingabe der Zeiten in Form einer Liste (da müsste ich auch erst drüber nachdenken). Was spricht gegen das Anlegen von mehreren Variablen, die die entsprechenden Zeiten enthalten. Oder wenn die Events z.B. alle fünf Minuten gestartet werden sollen, dann würde es ja auch ein Interval-Timer mit Zähler tun?

Viele Grüße
TriNitro
 
OP
C

cache7

Geocacher
Hallo,

danke für die Unterstützung.

Also die Idee ist, z.B. die Abfahrtszeiten eines Buses zu hinterlegen. Je nach Uhrzeit könnte die Person (im WherIgo) mit dem Bus fahren oder etwas anders vorschlagen.

Die Anfahrtszeiten haben normalerweise schon eine Regel. Am Wochenende ist diese aber anders und zwischendurch gibt es Ausnahmen. Diesen Fahrplan möchte ich nun (wenigstens vereinfacht) darin ablegen. Und da sich das Ding ab & an änders, möchte ich keine 150 if Bedingungen anpassen ...

Danke für die Tipps

cache7
 

TriNitro

Geocacher
Hallo cache7,

oh je, jetzt seh ich das Problem schon viel klarer!
Allein eine schnelle Antwort muss ich dir da erstmal schuldig bleiben. :???: Die erste Idee wäre natürlich auch bei mir ein unüberschaubares if/then/else-Konstrukt. Das würde zwar als Notlösung halbwegs funktionieren, ist bei Änderungen aber natürlich sehr unhandlich.

Fährt der Bus denn wenigstens in immer gleichen Abständen? Also einmal die Stunde oder sowas? Das könnte die Sache wenigstens ein bisschen vereinfachen.
Wäre es alternativ nicht wesentlich einfacher, statt einem reellen Plan einen virtuellen zu nehmen (bei dem man die Zeiten selbst bestimmen könnte). Ich weiß, das geht natürlich auf Kosten des Vor-Ort-Aha-Erlebnisses, könnte aber viel Arbeit und vor allem Frust ersparen.

Sorry, für die noch wenig hilfreiche Antwort, aber ich denk da noch weiter drüber nach!
Viele Grüße
TriNitro
 

bodenseepingu

Geomaster
Die Antwort ist recht einfach. LUA-Tables verwenden, dazu muss man z.b. in Urwigo
User-Funktionen verwenden.

Damit sollte es eigentlich gehen - allerdings habe ich keine Erfahrung gesammelt bisher, ob die LUA os-Funktionen unter denen sich Uhrzeit etc. verstecken tatsächlich auf allen Playern auch funktionieren - sonst wirds mühsam oder das ganze Konzept funktioniert nicht.

Also wenn diese Idee immer noch aktuell ist, dann empfehle ich
- ein kleines bisschen in LUA einarbeiten (http://lua.gts-stolberg.de/)
- erst mal prüfen ob die os-Funktionen funktionieren (garmin, android, iphone)
- mit LUA-Tables und User-Code Erfahrung sammeln

wenn das alles geht, sollte es nicht so schwer sein, Timetables und Koordinaten miteinander zu vermischen um z.b. zeitabhängige Anweisungen zu geben.
 
OP
C

cache7

Geocacher
Danke für den Hinweis. Aktuell ist die Frage noch, nur ist die Frage ob ich aktuell auch Zeit habe mir LUA anzuschauen :???: Klingt auf jeden Fall spannend und einen ersten Eindruck werde ich mir auf jeden Fall machen. Als Problem sehe ich hier schon wieder die Geräteunterschiede auf mich zukommen (der Rest wäre ja eher eine Fliessarbeit)

Danke für den Hinweis, das bringt mich auf jeden Fall in der Sache ein Stück weiter
cache7
 

bodenseepingu

Geomaster
also mach am besten ne testcartridge - ganz ohne Koordinaten - dann wird sich schon jemand finden, der mal ganz kurz was ausprobiert auf unterschiedlichen Geräten...vielleicht hab ich auch noch Lust dazu in dieser Richtung was zu probieren
 

º

Geoguru
Das grundsätzliche Problem bei Zeitfunktionen ist, dass die Geräte unterschiedliche Zeiten verwenden: z.B. nutzt Garmin GMT und Windows die eingestellte lokale Zeit. Dazu kommt dann noch dass die Zeit als sekunden seite dem 1.1.1970 (Windows) oder 1.1.1990 (Garmin) wiedergegeben wird. Oben genannte Funktionen können damit aber umgehen.
 

hihatzz

Geomaster
Hallo,
ich hab mal ein bisschen mit LUA gespielt.
Um die aktuelle Zeit auszulesen habe ich os.date verwendet, siehe hier

In der table depTime sind die Abfahrtszeiten des Busses mit Stunden, Minuten hinterlegt,
also hier im Beispiel 8:20h, 9:10h, 10:00h, 10:50h und 11:40h.

Die for-Schleife gibt den Bus aus der "erreichbar" (noch nicht abgefahren) ist.
Evtl. muss man noch die Tagesgrenze abfragen.

Code:
currTime=os.date("*t")
-- print("currTime: year:"..currTime.year.." month:"..currTime.month.." day: "..currTime.day.." hour:"..currTime.hour.." min:"..currTime.min)

depTime={8,20, 9,10, 10,00, 10,50, 11,40}

for i=1, #depTime, 2 do
    -- print(depTime[i]..":"..depTime[i+1].."h")
    if currTime.hour < depTime[i] then
        print("Bus: "..depTime[i]..":"..depTime[i+1].."h")
    end
    if currTime.hour == depTime[i] then
        if currTime.min < depTime[i+1] then
            print("Bus: "..depTime[i]..":"..depTime[i+1].."h")
        end
    end
end

Was ich nicht weiss ist wie die aktuelle Zeit "stimmt", d.h. auf den verschiedenen Systemen korrekt ist (Oregon, Android, IPhone). Auf Windows passt die Zeit. Inwiefern aber die Sommer-/Winterzeit das dann wieder um 1h verschiebt kann ich dir auch nicht sagen.
Vielleicht kannst du ja damit was anfangen.
 

bodenseepingu

Geomaster
Ich hab auch mal experimentiert

siehe weiter unten - man muss os.date statt os.time verwenden - die obige Lösung funktioniert !!! Ich lasse trotzdem diese Variante noch drin
Mit Urwigo - als Userfunktion - die obige Lösung mit os.time("*t") hat bei mir im Emulator eine Exception geworfen...darum hab ich das anders gemacht
Code:
require "os"

timetable = {}
timetable.anzahl = 3
timetable[1] = {}
timetable[1].hour=10
timetable[1].min = 13
timetable[1].busno = 17
timetable[2] = {}
timetable[2].hour=17
timetable[2].min = 40
timetable[2].busno = 8
timetable[3] = {}
timetable[3].hour=18
timetable[3].min = 11
timetable[3].busno = 3

function get_next_time(uhrzeit_in_sec)
  local i=1
  while ((i <= timetable.anzahl) and (uhrzeit_in_sec >= (timetable[i].hour * 3600 + timetable[i].min*60))) do
     i = i + 1
  end
  if i <= timetable.anzahl then
     print("take the bus "..timetable[i].busno.." at: "..timetable[i].hour..":"..timetable[i].min)
  else 
     print("no bus is running anymore")
  end
end

function usertest()

   local uhrzeit_in_sec = os.time() % 86400 --seconds since midnight
   print (uhrzeit_in_sec.." seconds since midnight")
   local index = get_next_time(uhrzeit_in_sec)
end

Bei dieser Lösung muss man aufpassen - 0 Sekunden bezieht sich auf GMT - d.h. es gibt hier zur Zeit 2h Unterschied - also ist das Ganze auch nicht Sommerzeit-Unabhängig - wenn die obige Lösung eine korrekte Zeit bringt, sollte man diese verwenden !!!
 

bodenseepingu

Geomaster
..Übrigens auf Android gab's zumindest vor kurzem noch einen Absturz wenn man bei Tables die Anzahl mit table.getn bestimmen wollte - ob das #depTime Konstrukt funktioniert, weiss ich nicht - das sollte man vor Verwendung testen..aus diesem Grund habe ich mir angewöhnt mit Tables zu arbeiten, die in sich selber die Anzahl noch tragen...nur falls sich jemand wundert..
 

bodenseepingu

Geomaster
Ich nehm alles zurück.

Die Seite, auf der Ich mich orientiere (Lua für Anfänger http://lua.gts-stolberg.de/os.php) hat einen Fehler

hier wird der Parameter ("*t") für os.time anstatt für os.date aufgezählt.

Das Konstrukt
Code:
local dtbl = {}
   dtbl = os.date("*t")
   print (dtbl.day.."."..dtbl.month.."."..dtbl.day.." "..dtbl.hour..":"..dtbl.min)
Bringt auf Urwigo im Emulator korrekte Ergebnisse - insofern halte ich die obere Lösung besser als den Senf, den ich von mir gelassen habe...
 

bodenseepingu

Geomaster
Die Lösung von hihatz ist ansatzweise gut, funktioniert so aber nicht (Stundenvergleich, Minutenvergleich, was ist wenn in einer Stunde kein Bus fährt.....etc.)

Hier eine grundsätzlich funktionsfähige Lösung:

Code:
timetable = {}
timetable.anzahl = 7
timetable[1] = {}
timetable[1].hour=10
timetable[1].min = 13
timetable[1].line = "Bus 17"
timetable[2] = {}
timetable[2].hour=17
timetable[2].min = 40
timetable[2].line = "S 8"
timetable[3] = {}
timetable[3].hour=19
timetable[3].min = 40
timetable[3].line = "U3"
timetable[4] = {}
timetable[4].hour= 19
timetable[4].min = 41
timetable[4].line = "U4"
timetable[5] = {}
timetable[5].hour= 19
timetable[5].min = 42
timetable[5].line = "S8"
timetable[6] = {}
timetable[6].hour= 19
timetable[6].min = 43
timetable[6].line = "U5"
timetable[7] = {}
timetable[7].hour= 23
timetable[7].min = 30
timetable[7].line = "Nightbus 1"

function get_next_time(timetbl)
  local time_sec = timetbl.hour * 3600 + timetbl.min * 60
  local i=1
  local msg = "It is now "..timetbl.hour..":"..timetbl.min..", "
  while ((i <= timetable.anzahl) and (time_sec >= (timetable[i].hour * 3600 + timetable[i].min*60))) do
     i = i + 1
  end
  if i <= timetable.anzahl then
     msg = msg.."take the line "..timetable[i].line.." at: "..timetable[i].hour..":"..timetable[i].min
  else 
     msg = msg.."sorry, today there is no connection anymore"
  end
  return msg
end


function bestimme_abfahrzeit()
  local currTime=os.date("*t")
  return get_next_time(currTime)
end

bestimme_abfahrzeit() wird dabei als user-Code von urwigo aufgerufen und liefert den korrekten Text zurück.

...Jetzt kommt das Aber:
- Emulator: perfekt
- Android/WhereYouGo: Obwohl im Log-File die korrekte Uhrzeit für Logs angezeigt wird, bringen die OS-Funktionen die GMT-Zeiten - wie ein Garmin reagiert weiss ich nicht - ich häng gleich mal das urwigo file und das übersetzte gwc-File für Tests auf Garmin / Apfel als Zip-File ran.
 

Anhänge

  • oepnv.zip
    6,8 KB · Aufrufe: 35

bodenseepingu

Geomaster
Hier nochmals eine verbesserte Version - mit eingebauter Zeitzonenanpassung und Anzeige
der Zeit wie das Gerät diese dann ausliest.
...Test auf Android steht noch aus.

Wäre schön, wenn noch jemand auf anderen Geräten testen würde und hier die Ergebnisse posten..
 

Anhänge

  • oepnv.zip
    8,2 KB · Aufrufe: 45

hihatzz

Geomaster
Ich hab's mal getestet, siehe Bilder:

Android Samsung Galaxy S (I9000) (mit Froyo 2.2): os.date liefert UTC time
Oregon 300: Zeit ist local time.

Ich habe dann das Oregon ausgeschaltet und im Haus nach ca. 5min. wieder eingeschaltet.
Auch ohne GPS-Zeit hat die Zeit gestimmt, d.h. eine interne Uhr läuft dort weiter.
 

Anhänge

  • oepnv_android.jpg
    oepnv_android.jpg
    49,8 KB · Aufrufe: 569
  • oepnv_oregon300.jpg
    oepnv_oregon300.jpg
    42,1 KB · Aufrufe: 569

bodenseepingu

Geomaster
hey danke, ich glaub wenn man so was macht ist aufgrund der Geräte- und Player-Vielfalt die eingebaute Zeitzonenanpassung sicherlich sinnvoll...
 

bodenseepingu

Geomaster
bodenseepingu schrieb:
..Übrigens auf Android gab's zumindest vor kurzem noch einen Absturz wenn man bei Tables die Anzahl mit table.getn bestimmen wollte - ob das #depTime Konstrukt funktioniert, weiss ich nicht - das sollte man vor Verwendung testen..aus diesem Grund habe ich mir angewöhnt mit Tables zu arbeiten, die in sich selber die Anzahl noch tragen...nur falls sich jemand wundert..


In der Earwigo-Mailing-Liste liest Jan Matejek mit - er ist nach eigenen Angaben der Entwickler von OpenWIG, das im Android WhereYouGo Player verwendet wird.

Ich habe deshalb dort mal den table.getn Fehler bei Android gepostet, evtl. tut sich da was in den nächsten Versionen und der Fehler wird behoben.
 

bodenseepingu

Geomaster
Hier die Antwort von Jan Matejek

yeah, table.getn is deprecated and you aren't supposed to use it. #tablename is the right syntax
(that said, in the new core table.getn is implemented because too many people were using it. aargh. please keep avoiding it. also, with the new core, most PlayAnywhere cartridges work fine. but that is code that is not in WhereYouGo yet)


- date functions have a different behaviour than Garmin - for currTime=os.date("*t") WhereYouGo delivers GMT time and Garmin delivers local time


now this is a proper bug
 

DG5GSA

Geocacher
Na da denke ich, bin ich mit meinem Problemchen ja genau richtig.

Wie schaff ich es, dass die Cartridge, z.b. eine Stage erst ab 20:30 Uhr freigibt.

Ziel ist die Sicherung eines N8 WIG. Damit die Cacher erst zu einer bestimmten Uhrzeit loslaufen können.

Leider habe ich dazu noch nichts gefunden, das hier geht aber wenigstens in die Richtung.

Danke

Stefan
 
Oben