howto start using jeemon from scratch

(21 posts) (4 voices)

Tags:

No tags yet.

twinkel

I am having lots of fun playing with all these nodes, sensors and other toys!
I only find challenges running JeeMon on my debian box. In the svn set I downloaded I found no executable. The turnkey version runs my demo ok so I copied the application.tcl from JeeMon-tcl. My remote node sends successfully to my USB-v3 running RF12demo.
webserver says: can't find /. (changed port to 8888 in application.tcl btw).
The first thing I want to achieve is see log lines coming in (to where?) and continue from there.

Posted 21/04/2010 09:37:54
twinkel

how can i edit my post? I meant ./JeeMon-jcw/application.tcl and config.txt. I now have a running remote light sensor, but maybe I am struggling with RF12 definitions in ./config.txt?
also , is there an option to start without the gui? I tend to run most things via ssh2.

Posted 21/04/2010 12:14:17
jcw

JeeMon is currently a bleeding edge thing - with emphasis on bleeding. Not ready for general use. Best I can point to is the page.
There are a few examples in the subversion directory, and some in the weblog - such as . Most JeeMon-related posts should be available via .
Re without GUI: yes, it's all dependent on what you have in application.tcl - if you don't start Tk and don't call modules which do, then it'll all remain in command-line mode.
Re editing posts: there's an "EDIT" link underneath your post, but only for 60 minutes after being submitted.
I'd like to write some posts about getting started with JeeMon. Been a bit too busy with the hardware side of things lately, but I hope to be able to give the software side of things more attention now. I welcome suggestions on how / where to start.

Posted 21/04/2010 14:33:05

twinkel

ok, maybe I can help you out ;-)

I found it difficult to migrate from demoset to working environment. I have a knowledge gap here being a tcl-noob, and reluctant to learn tcl for a start. Most trials were unsuccesfull 'cause I started ../JeeMon from within the rig... I did not realize that config.txt had to be in the rig. I was unsure what code to run in the JeeNode that I'm using as a JeeLink in order to enable wireless transfer. And I find it sometimes difficult to value the doc, given the fact that JeeMon is going through major enhancements as well.

Going through lots of weblog-docs and talks and with some trial and error I now have a small setup, based on 1 AnalogPlug directly talking to JeeMon, but.... I am now stuck with:

                     > analogPlug JeeSketch on usb-A600cK6z
    14:15:46.026     warn usb-A600cK6z: unknown or ambiguous subcommand "namespace
    14:15:46.027    einfo unknown or ambiguous subcommand "namespace": must be ....
                    while executing ....
    "info object namespace [uplevel 1 {self class}]"
        (procedure "classVar" line 3)
        invoked from within
    "classVar recent"
        (class "::JeeSketch::ListenerBase" method "onMessage" line 8)
        invoked from within
    "my onMessage id $id info $info"
        (class "::JeeSketch::ListenerBase" method "onReceive" line 4)
        invoked from within
    "my onReceive $text"
        ("try" body line 10)

btw: I had several occasions where programming the id of a transmitter with RFM12demo was reset to 1i, only when I used a `,a` afterwards, not with other commands like ` s`.

Oh, and I appreciate the good work that you are doing very much.

Posted 22/04/2010 12:32:17

jcw

Yuck. And I see that I made lots of assumptions - I always run JeeMon as ./JeeMon, i.e. in same dir.
- you can look in application.tcl to see where config.txt is expected to live - if you use a JeeNode as central node, put RF12demo into it [] - docs: yes, very awkward that it lags or is absent, but main core should start to settle now
More links with examples, perhaps of use here:
The error message above doesn't have enough info for me to help. Could you post or email the "sketches/analogPlug/host.tcl" code you've got so far?
Would it help if I create and document a few demos from scratch? I generally find it easier to evolve and extend working code when trying out new stuff, than stumbling from one baffling behavior to the next...
[] - I'm starting to switch over to "sketches/central/central.pde", but that's still work-in-progress.

Posted 22/04/2010 12:56:57
jcw

Re "id of a transmitter with RFM12demo was reset to 1i" - hm, I don't know what could cause this (other than typing "1i" by accident). If you manage to capture a scenario which I can reproduce, that would help.

Posted 22/04/2010 13:03:23
twinkel

I don't have a problem with lagging docs and appreciate your help to get me started. I am using your analogPlug host.tcl. I added an extra loglines which shows it's starting with the message `B i2 g5 @ 868 MHZ` then runs through the whole setup method but window `.ap2` is not created (the empty main.tcl window is always there).
I added Log commands to method VOLT and onCleanup but apparently it never gets there.
The existing docs regarding JeeMon are ok, up to the point where I wanted to start building a 1-plug rig. All the available examples seem to leave the whole picture blank with me. That leaves me running around in circles.
I also did not know how to start the development set. now I know: in the root directory of where all the JeeMon stuff is> `./JeeMon JeeMon-jcw` does the trick. This gives the same result as above btw (svn'd 20 april).
[EDIT]: the oscilloscope does work btw!

Posted 22/04/2010 13:44:54
jcw

I suspect that the auto-start logic is making things needlessly complicated. When a serial port is setup as being a "JeeSketch" (I know, the names get a bit tedious), then JeeMon waits for an incoming "blah]" line and tries to start the "blah/host.tcl" script if present. My thinking was that I could plug in whatever JeeNode or Arduino I wanted, and JeeMon would launch the matching script to deal with it.
Then came the wireless part, whereby you have to config that say "node 12 is running a 'blah'" sketch. Then, the moment a packet comes in from node 12, JeeMon again launches the matching script. So turning on a node is like plugging in a USB device.
All nice and well, but for now I think it just makes the whole startup mechanism a bit too magical (and hard to get right, initially).
Bear with me. Let's see if this would be a practical way to stabilize and document things:
did you see the examples/ dir in JeeMon? - three examples, simple, but perhaps not that useful... howto #1 could be: hook up JN, upload sketch to it, launch JeeMon, see serial output howto #2: upload modified sketch to turn it into remote JN, hook up 2nd JN or JL running "central" sketch, launch JM, see incoming packets howto #3: add decoders, to turn incoming packets into msgs such as "VOLT xys", etc? howto #4: ... ?

Posted 22/04/2010 14:44:44
jcw

Or maybe describe the big picture first (a little WSN, with data collection and ...). Then take all the steps to implement it.

Posted 22/04/2010 14:46:32
twinkel

I like the incremental approach a lot. It would give a chance to see where he (eventually) gets stuck. If my system grows with each howto, so will my inner overview of the whole thing. And that would invite me to try and add my own wishes and go back one step if unsuccesfull.
but ehm... where I did get stuck for instance (assuming i could apply my shell experience,) is how to start the examples? `./JeeMon examples/serial2.tcl` ? ... no `cd examples && ../JeeMon serial2.tcl` ... no which possibility that I didn't try is the right one?
btw, I have removed all the RF12 stuff from my sketch. I now get an ap2-window but when data comes in, error again. Since i don't have an analogPlug I am back to one of your earlier examples with an LDR direct on port3.

Posted 22/04/2010 15:46:18
jcw

Ah, yes, that's special-cased, and highly illogical: ./JeeMon examples serial1
I was trying to avoid one dir per tiny example, with only one little file in it. But it's probably better, with a README etc.

Posted 22/04/2010 17:23:04
twinkel

I would think a whole lot of directories with examples in them would be overwhelming. Why not have all examples in 1 dir, and document them a bit more in the source. That would save the need for a separate README as well.
Also what could maybe have helped me - and to avoid having to build a huge pile of docs right now - is to have the simple setup e.g. 1 JeeNode (with 1 LDR or potmeter) via serial and/or via a JeeNode-usb or JeeLink set aside in a separate directory. This could show the measured value in one of your already existing gadgets on the desktop. and invite the user to run it and start building up from there. A simple `./JeeMon example lightSensor` would do the trick, right?

Posted 22/04/2010 18:04:24
jcw

Ok - thanks, very helpful. You're right, I don't need to change the whole setup around again - just stick with it, and make it easier to follow things step by step. The scope could go in here as well, btw (ah, but wait, that requires a GUI setup, not a remote Linux box).
Still some things to ponder about w.r.t. platform differences, but yeah - this is starting to make a lot more sense now.
Also, JeeMon, when started without args, should offer a bit more direction than what it does right now. Without args is the default case for Windows and MacOSX. I wonder whether people using Linux and exploring the Jee Labs stuff are likely to use the command line all the time, or whether there too people will browse and launch apps from a GUI desktop manager more and more?
As developer, I'm mostly command-line oriented (even on Mac), but for this physical computing stuff maybe the shift is towards letting newcomers explore all this under-the-hood stuff?
Anyway. Not so important. What matters is that I can start making JeeMon a more fun experience :)

Posted 22/04/2010 19:02:16
zooer

Hey, don't know if this fits here, but I'd like to share my vague ideas of how I hopefully will be using JeeStuff in a couple of months. Perhaps there’s interest for some sort of group development to ease up JCW’s load, at least once there’s enough brain power speaking Jee.
Home server with adequate resources (enough CPU power + disk space) is running JeeMon 24/7 along with some other home automation software (most important one is LinuxMCE). Secure outside access.
The house is equipped with, let’s say, 30 JeeNodes running various setups. Each room has at least a JeeNode equipped with Rooms Board.
JeeMon is coordinating several tasks: 1. it listens JeeNode messages, and 2. makes various queries to JeeNodes 3. logs data and events 4. produces web pages for data visualizations 5. controls JeeNodes (e.g. RGB lights) 6. talks with LinuxMCE (JeeNodes may be controlled via LinuxMCE, LinuxMCE may respond to JeeNode data).
Simply written down, but the implementation is something else. I suppose the ideology of JeeMon supports well the modularity of various tasks?

Posted 23/04/2010 13:04:56
jcw

Nice plans - should match fairly well with what I'm trying to do with all this stuff.
Modularity - absolutely, that's probably the hardest but also the most important part I'm trying to get right in JeeMon.
The general direction for JeeMon is to act as a switchboard and combine many functions from Arduino IDE, Processing, database storage, and webserver into one. All optional, and each of these usable in isolation, so that you can also hook up your own favorite programming language or database (via files, sockets, pipes, webservices, executables, scripts, etc).
JeeMon is not about lock-in. It should be fun and effective for non-programmers as well as seasoned software developers.
Quite a challenge, evidently...

Posted 23/04/2010 14:37:24

twinkel

Have moved JeeMon from my debian server to my ubuntu laptop now.

    RF12 JeeSketch on usb-A900adhF
Comes up now automagically right after starting JeeMon, which it only does on my Debian stable box when replugging the JeeNode-usb that I am using as a Jeelink. But that was an experiment with central.pde and I should be running RF12demo, right?

Unfortunately, still the same error as before, using the setup from the svn, with modified USB id and adapted RF12/ { 868:5/ { 2/ { type rooms }. This time no serial data, only airbound, still gives as before:

    einfo unknown or ambiguous subcommand "namespace":  etc.etc.
Oh and I used the JeeMon executable from the demo set, since I can't find an executable in the  svn.

Oh, I now see with RF12demo it works much better, but prints:

    (adhF) OK 34 1 0 0 0
    (adhF)  -> ack
should it not invoke ./sketches/rooms/host.tcl now and start parsing?


				Posted 29/04/2010 15:41:47


	
		
			
								
					jcw

				
			
			
				
> Oh, I now see with RF12demo it works much better, but prints:
> 
>     (adhF) OK 34 1 0 0 0
>     (adhF)  -> ack
> 
> should it not invoke ./sketches/rooms/host.tcl now and start parsing?
Right now, the central.pde and RF12demo sketches are almost the same. The key difference is the way they report themselves, i.e. as "[central] ..." vs. '[RF12demo] ...". This one line makes all the difference for JeeMon.
So the error you're getting is actually a sign that JeeMon is properly picking up the connection (and then failing somewhere further down the line).
Could you email me the full error message and your "application.tcl"? It's probably something silly mistake by me...



				Posted 29/04/2010 18:12:01
			
		
	
	
		
			
								
					jcw

				
			
			
				
Just wanted to report that @twinkel and I solved the issue via email and nailed it down as a slightly-too-old version of Tcl in the Linux builds of JeeMon. I've adjusted the code to not rely on a minor new feature. Also added some logic to pulse DTR on serial port open, so that JeeLinks and JeeNodes will be reset, same as on Windows and Mac.



				Posted 01/05/2010 15:09:28
			
		
	
	
		
			
								
					zooer

				
			
			
				
Hi, seems that I'm struggling with the auto start logic, too. 
Could anyone give a simple example how to call a function (that is e.g. in let's say hello.tcl) from the main application.tcl? I've tried experimenting for hours, but just cannot make it. 
Cheers, 
Zooer



				Posted 23/07/2010 10:57:56
			
		
	
	
		
			
								
					stef007

				
			
			
				
In your application.tcl:
include the source using this line:
source hello.tcl
call a function with name "testfunc" like this:
::application::testfunc
you need to adres global vars like that also:
$::application::somelist
It looks like the application.tcl is loaded by jeemon into the "application" namespace.
Ofcourse if your hello.tcl is loaded from somewhere else, its functions might be in another namespace. Or perhaps your hello.tcl will define one. Then you must prepend the appropriate namespace when calling its functions.



				Posted 23/07/2010 16:00:36
			
		
	
	
		
			
								
					zooer

				
			
			
				
Thanks stef007!
I had noticed the "source" but it didn't really make sense at that time since most applications in jcw's svn have the same function (setup). Also, just wanted to proceed quicly. Understood that using source would create name collisions. Also saw this JeeSketch.tcl which at that time I though that it takes care of reading the tcl codes and making some magic that all the codes are included. 
OK, the above illustrates my understanding/experience with tcl and JeeMon. 
Now studying a bit more into these, namespace especially. Also hoping that jcw will get to fill-in the section three at http://cafe.jeelabs.net/sw/jeemon/startup/.
Cheers,
Zooer



				Posted 23/07/2010 21:39:47