PiDome Domotica/Home Automation

[Arielpod]

Ok, thanks! I'll reinstall it in the meantime just to find out if that would help. BTW, in lsusb, the device appears as 'qinheng electronics hl-340 usb-serial adapter'.

Patiently waiting for some news then. Cheers!

[John]

Would you by accident also have the vid and pid from this device?

[Arielpod]

This post is deleted!

[Arielpod]

I'll check that when I get home.

[John]

That would be cool, it then could be included as a default "considered good and save to use" device if it performs as it should. The interface will also be added though, but in a later stage

[Arielpod]

Ok, it's 1a86:7523

[John]

Thanks, i will add this one to the safe list (for the time being). I will notify you when it is available.

[John]

@Arielpod said:

Ok, it's 1a86:7523

I have included the mentioned device in the latest build. I do have to say that this is a quick build for testing purposes so some functionalities may be broken.

The build for now is only available on the build server at: http://builder.pidome.org/job/PiDome Server platform snapshot build/lastSuccessfulBuild/

This build does require a clean installation though, but is update safe so when newer builds are available you won't loose any data.

[Arielpod]

I'm not quite sure what you meant by "clean installation" but I just removed the directory of the previous installation and downloaded the one you've given the link to. Every time I connect the device I get an error:

[John]

Resolved on the build server and available in the link posted above.

[Arielpod]

Great, it's working! Thanks a lot.

[jonnyfishman]

Hi, looking for some advice on connecting sensor to PiDome. Think I've followed the instructions correctly but when connecting sensor under 'Devices' I get this message 'New device: Possible new address: 1 if not occupied before adding (Restart node after assigning).' and nothing to choose.

My custom device settings are as follows with the Arduino CHILD_ID set to 1. Is there something obvious I've missed or is S_MOTION not included yet?
Thanks, Jon

[John]

@jonnyfishman
Hi,

If you use S_MOTION in the Arduino code then the group id should be 1 and the data control should correspond with the V_ value used in the Arduino code.
With the motion detection you can use the boolean data type (the integers 1 and 0 will be correctly handled). This will make it easier in triggers and automation rules where you can select "true" or "false" from a drop down instead of filling in the 1 or 0.

By clicking on the "Add sensor node" you will get a popup where you can choose the device created in the device editor.

[jonnyfishman]

Hi,

Thanks for the reply. I have checked the settings and changed the Group ID to 1 and the Data field ID to V_TRIPPED, using the Boolean option.

The problem I have is that when I click 'Add sensor node' I get the message 'Done (no choice of device)' and nothing is added in devices and the error log shows the following:

10-10-2014 21:59:53 0;0;3;0;9;send: 0-0-255-255 s=255,c=3,t=4,pt=0,l=1,st=fail:1
10-10-2014 21:57:50 Trying assigning address '1' to a new node

Thanks, Jon

[John]

Do you see the device back in the "New nodes presentation" with an address when you restart the node? this would mean that the node did not got it's address assigned. I have understood from @hek that the line:

10-10-2014 21:59:53 0;0;3;0;9;send: 0-0-255-255 s=255,c=3,t=4,pt=0,l=1,st=fail:1

does not say if that it has failed or succeeded.

The system needs a Node with an address before it can be added, the reason why there is no device selection is because of the above line can not guarantee a success or a failure. So after "Add sensor node" you have to restart the node, because only then the address is known. I should change the name of the button though to "Assign address" for making it more obvious.

[jonnyfishman]

Awesome, that sorted it! Thanks. Think I was leaving to long a time (or to short) between restarting the node. Really enjoying the Server interface, the macros and automation rules are really powerful (just need to get some more nodes to really have a play).

I saw on one of your posts that battery monitoring is a to do, has that happened or is it still in the pipeline. Also is there a way to trigger an email as I don't have a SMS dongle (thinking I could do it with a sensor set as RelayActuator on a GPIO pin on the pi that would trigger a PHP mail function but there's probably a more efficient way to do it).

Sorry for all the questions...

[John]

Sorry for the late response, had a meeting with my (hardware) development partner in crime this weekend...

Yes this still is in the pipeline, i think it has slipped between all the other work currently going on, as the same is with the email notification. You would help me a lot if you would make a feature request for the both above at: https://bitbucket.org/pidome/pidome-server/issues?status=new&status=open (via the create issue link). It is our main global to do list ;).

No problem, all questions are welcome!

[fogsvans]

First of all - great work with PiDome!

I've been trying to create a Custom device with a color picker but I always get following message:

and in appLog this appears:

[tbowmo]

Tried to use the xbmc 13 media plugin, but after enabling it, it shows up as XBMC 12 in media plugins. Also my XBMC box tells me that a version 12 client is connecting to it.

Also, I noticed that it only shows "playing" state, when I'm watching a movie from local storrage. If I watch live tv, or use a streaming plugin, it seems that pidome doesn't know about it. Is this because of lack of functionality in xbmc protocol?

/ Thomas

[John]

The above both are correct, As long as the server is an Alpha version all supplied downloads are automated this also means any test build is also supplied.

The color picker error is due to the fact the color picker is currently being modified to support different color schemes and color set possibilities. It was set to only accept hex parameters. This is being changed to HEX, RGB, HSB and Kelvin with color modes: HSB, HSL, CIE and RGB. So this control is currently heavily being overhauled and also in snapshot state.

The functionalities of XBMC 12 and 13 regarding exposed for base XBMC 12/13 functionalities are the same. It is correct that the streams and live TV are not included yet. I have created a request at: https://bitbucket.org/pidome/pidome-server/issue/133/extend-xbmc-plugin-func to extend the features. The build server does have an updated version where correct plugin usage is shown.

I do suggest to keep an eye on http://builder.pidome.org/view/Snapshot builds/job/PiDome Server platform snapshot build/ and report bugs/issues found not related to MySensors on https://bitbucket.org/pidome/pidome-server/issues?status=new&status=open

[tbowmo]

@John
I tried the "latest" snapshot (downloaded today at 20:30 CET).
After starting pidome up, went to the peripherals page, I then connected the mysensors gateway (arduino nano with the default serial gateway sketch) to my raspberry. Nothing happens in pidome at all..

Shouldn't it popup with something about the new peripheral that was attached?

Regards
Thomas

[John]

@Thomas-Bowman-Mørch

Hi Thomas, Yes it should, also security has been tightened in the server which in some cases causes the real time web interface updating to fail. Does clicking the peripheral pages again show the nano? Also is the nano a clone or the real thing?

[tbowmo]

@John

Yeah, did also notice that it asks for user/password when opening the PiDome admin interface now. Nice thing

Tried to reload the page, etc.but it didn't help.

The gateway is a clone, with a PL2303 as usb->serial gateway.. I noticed that the real nano is using a ftdi chip.

Does PiDome check the VID/PID of the usb device, in order to figure out what it is?

/ Thomas

[John]

@Thomas-Bowman-Mørch

Hi Thomas, yes it does. A feature build in is that users won't have to do anything if a specific device is connected via USB. It will then give the user the possibility to choose a driver based on the vid/pid in this example usb-serial so you should get the option to set serial options.

An example: When a specific RFXCOM device is supported with fixed settings and connected to usb the server will autoload everything for this device and the end-user would only have to add devices.

There is an interface on it's way that when an vid/pid is not recognized the server will check what kind of usb device it is and present the possible options for this device. You can then set the appropriate driver type and this then will be stored on the server. So every time this specific device is connected you will be presented with the correct device options. Also in the future we will build a webservice which will be capable of sharing vid/pid driver types and download appropiate drivers if the user wishes to do so.

To make a long story short, what vid/pid is it using so it can be added as default known?

[tbowmo]

@John
Thanks John...

The usb vid/pid is as follows

idVendor 0x067b Prolific Technology, Inc.
idProduct 0x2303 PL2303 Serial Port

taken from lsusb -v

/ Thomas

[John]

@Thomas-Bowman-Mørch It wil be included in the next build (411, current is 410). This one will be build tomorrow, let me know how the device handles.

[tbowmo]

I patched the database in my install, by taking the sql update file you created for my device, and changing the db schema.

I can now add mysensors to pidome! Yahoo!

Next step is to get something usefull done with it

/ Thomas

[John]

Good! Did you do this manual or just stopped, overwritten and restarted the server? The latter would have precedence ;). Updating happens automatically.

If you did this manual make sure to execute

PRAGMA user_version=4;

in the SQL editor to make sure the DB is consistent with the configuration file otherwise the server will keep on trying update the database. To check the version you can run "PRAGMA user_version;" without the "=4" to see which version it currently is.

Report any findings you have so i can make the plugin better!

[tbowmo]

I shutdown the server, put the file 4.sql in the Database/private/update directory, also updated mysensors.default.config to reflect latest db version, and then restarted the server.

In the meantime while trying to add sensors, I have replaced the entire pidome with the latest snapshot build. But it still gives me grey hairs trying to trying to figure out how to add the first temperature sensor node (based on the dalas ds18s20 demo sketch comming with mysensors code). It has two dalas chips, so reporting two temperatures, gw.present(0, S_TEMP); gw.present(1, S_TEMP);

In PiDome, I have created a custom sensor, with two groups (0 and 1), each having a datafield configured as:
Control ID: 0
Control name: Temperature
Datatype : Float
Graph : timeseries (average)
Suffix : C
Floormap type: Temperature

After adding the mysensor node, with this custom sensor description, I then go to "Control/Views" and "Devices" clicking on my new sensor, it repports 0C for both sensors, The timestamp is updated to the time that the node last send in it's temperature.

I can't seem to figure out why it repports 0 as temperature. Looking at the data from the gateway with minicom (while server is shutdown), it does repport correct temperatures for both sensors attached to the remote node.

Am I doing things wrong here, or have I found a unknown "feature"?

/ Thomas

[John]

@tbowmo The control id should be the V_VAR naming and the control id you have used as group id.

More info can be found at: http://pidome.wordpress.com/2014/08/10/added-partly-mysensors-org-wireless-devices-support-api-1-4-beta/

[tbowmo]

That did it.. Changed the control id, to V_TEMP on both temperature data fields

And now I am able to get temperature measurements..

[John]

Good to hear!

Uhmm.. read...

[John]

@tbowmo

Regarding the update method you did

"I shutdown the server, put the file 4.sql in the Database/private/update directory, also updated mysensors.default.config to reflect latest db version, and then restarted the server."

Could possibly mess things up.

This method:
"I have replaced the entire pidome with the latest snapshot build" can also be "I have overwritten the entire pidome with the latest snapshot build". The last method will auto-update.

With a database update there also is an high possibility of changes in code. Fortunate DB structure update version 4 only adds data

[tbowmo]

@John
Well i'm still testing things out, so if something goes wrong, I delete everything (including databases), and start all over again.. That was what I meant by "I have replaced the entire pidome with the latest snapshot build"

Still experimenting with adding sensor nodes. Think I have to solder up a couple of extra nodes, just to have something to generate input, and to send some output to (Have the parts ready for 4 more nodes)

/ Thomas

[tbowmo]

One thing that is a bit unclear to me..

If I have a node with 3 temperature sensors on. They are made with gw.present(0, S_TEMP); gw.present(1,S_TEMP)...

This node also functions as a thermostat, using sensor 0, so when temperature is below setpoint make output go high

Now in pidome, I have made a sensor node with 3 groups (1 for each S_TEM), each one of them defines one datafield with V_TEMP as ID.

I also want to be able to set the target temperature for sensor 0 on the node (that is, the node itself turns on the heater until desired temperature is reached)

How should I define this in pidome? Should I make a new group, and attach a slider to that one, in order to set a value in the node? Because I can't see any option to send a datafield value to the node.

/ Thomas

[John]

@tbowmo Sorry for the late response, was at a conference yesterday.

It depends on how to interpret the value to be send. If you want to let the node control the heater, you should on the node create for example a threshold vairable let's say "int trigger value". If you would create a VAR_1 control which can be a slider in the node 0 group of type int and set a minimal value of 0 and max value of for example 50, you will be able to send a value to the node between 0-50.

On the node you should listen for incoming data for sensor 0, with variable VAR_1. and store it in the var on the node.

When you change the slider values the value is immediately send.

[John]

I know it has should been added earlier, but you can now add battery level to a device added to the server.

When you are creating your own device in the visual device editor do the following to show the battery level:

• Drag an drop a group to the device declaration field. You can give it any name you want, but the group id must be named "INTERNAL"(capital letters without the " (quotes)).
• Drag and drop a data field control to this group. You can give it any name. but the id must be "I_BATTERY_LEVEL" (also without the quotes).
• Set the datatype to "FLOAT". All battery levels in the server are handled this way.
• If you want, you can select "Battery (0-100%)" as a visual type. This is for future references when the server is able to report low battery levels to users and visualize this in clients.

That's it.

Cheers,
John.

P.S. We are on a level where we can start defining an online servers for users to share custom devices. We hope to have this available in a month or 2/3. So if you then create a MySensors node and added a custom device on the server. You can share this custom device setup with others also creating your MySensors node.

[tortoisedoc]

Hey;
can someone pinpoint what the "Waiting for gateway" means?

Thanks!

[John]

Sorry for the late response!

The server waits for a message from the gateway which tells the server it is ready to serve data. When you attach the gateway to your pc, and watch it in the terminal, do you see a "Gateway ready" message?

John.

[tortoisedoc]

@John said:

Sorry for the late response!

No problem

The server waits for a message from the gateway which tells the server it is ready to serve data. When you attach the gateway to your pc, and watch it in the terminal, do you see a "Gateway ready" message?

John.

Yes, as a matter of fact i do (via ssh -> miniterm.py on RPi)

EDIT : I Just now realized this is not necessarily the "Gateway ready signal"
Btw is there support for mysensors from the RPi SIO pins? It would be great to not need to use the FTDI

[John]

Well, this IS the gateway ready message. It is an internal message the "3". And it is saying "14" which is the ready message (i should have said startup complete). I will take a look into it. Your sure using the same settings as with miniterm?

The second remark you gave. I will soon start with the driver which will support mysensors using the rpi pins. Highly possible this will start somewhere next. Already are in contact with an user who also wants to use mysensors this way

[tortoisedoc]

About the GW : Yes, same settings than the pidome server (no parity, 1 stop bit, 115200 bauds, 8 data bits); you can see it from the screenshot.

About the SPI : Great to hear! I can imagine switching from the USB driver to the SPI's should not be too much of a hassle; I wanted to have a look at the code myself (out of curiousity), but did not get to it yet.
One question, I noticed the tty used is exclusively locked by the server once it is started;
I believe it would be of great help to be able to access it at the same time as the pidome server, from the shell (say with miniterm.py), for debugging purpouses.

[John]

Yes, i will also be using mysensors that way, I will then have an USB port free for RFXCom and another one for my IR transceiver (my hub died). When available i will tweet it and put a notification here.

I will take a look into using JSSC_NO_TIOCEXCL when connecting to prevent the exclusive lock.

[John]

@tortoisedoc I have updated the serial driver not to do an exclusive lock. It is available on the build server. Currently not tested, i have no (usb) serial devices running earlier then the day after tomorrow. You should be able to debug the channel.

Anyway, data flow should be as following:
<- Wait for the gateway to receive the ready message
-> send out a request for the version
<- receive version
*remove the waiting for gateway message with the gateway version number in the web interface.

[tortoisedoc]

@John Sorry for the late reply;
I just managed to fry two arduino's today thanks to my stubborness to try to get them powered with a 9V on RAW. So, I am stuck until I can find more arduinos
It appears the regulator can only take so much incoming current if the output current is very low (3.3V in my case). Otherwise, it will overheat and bang, that's it.

[John]

Well, i was also quite busy today (doing some arduino style "modifications" to a slot car track with my son), so no problem, otherwise i had to excuse ;).

But uhm.. you are quite, how do i call it, enthusiastic.. Take your time, i will ask around regarding the address assignments and gateway ready message. If you find something, just mail to support at the project name with dot org. This is watched more closely then the forum

[tortoisedoc]

@John said:

Well, i was also quite busy today (doing some arduino style "modifications" to a slot car track with my son), so no problem, otherwise i had to excuse ;).

But uhm.. you are quite, how do i call it, enthusiastic.. Take your time, i will ask around regarding the address assignments and gateway ready message. If you find something, just mail to support at the project name with dot org. This is watched more closely then the forum

You mean because of the Arduinos or because of fast moving

[John]

@tortoisedoc The Arduino's :x

[tortoisedoc]

@John Yeah, well, seems trusting teh internet is not cutting it anymore (up to 12 V should be supported on the RAW-in according to the arduino website). But meh! One of the two is not dead yet, I can still power it on (and it works!).
So here some miniterm.py data with the build of 8.12:
Notice the "25" in front of the 255 (with the "stable" build it was 255)!

--- Miniterm on /dev/ttyUSB0: 115200,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
0;0;3;0;;read: 25-255-0 s255,c=3,=3,pt=0,=0:
255;55;3;03;
0;0;3;0;;read: 25-255-0 s255,c=3,=3,pt=0l=0:
255255;3;0;;
0;0;3;0;;read: 25-255-0 =255,c3,t=3,pt=0l=0:
255;55;3;0;3;Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 552, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/threading.py", line 505, in run
self.__target(*self.__args, **self.__kwargs)
File "/usr/bin/miniterm.py", line 200, in reader
data = self.serial.read(1)
File "/usr/lib/python2.7/dist-packages/serial/serialposix.py", line 456, in re ad
raise SerialException('device reports readiness to read but returned no data (device disconnected?)')
SerialException: device reports readiness to read but returned no data (device d isconnected?)

Seems also the miniterm is not cutting it for some reason (port disconnected?)

BUT still no success yet. Node keeps on asking for new ID...next, will generate a trace dump...

================== BEGIN ===================

2014-12-09 13:24:03,320 [Thread-12] TRACE org.pidome.server.connector.drivers.peripherals.hardware.PeripheralHardwareDriver - Data received from device: 65 byte(s)
2014-12-09 13:24:03,324 [Thread-12] TRACE org.pidome.driver.driver.nativeMySensorsDriver14.NativeMySensorsDriver14 - Received from hardware driver: 0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:
255;255;3;0;3;
2014-12-09 13:24:03,338 [Thread-12] DEBUG org.pidome.driver.driver.nativeMySensorsDriver14.NativeMySensorsDriver14 - Handling internal: 0;0;INTERNAL;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:
2014-12-09 13:24:03,340 [Thread-12] DEBUG org.pidome.driver.driver.nativeMySensorsDriver14.NativeMySensorsDriver14 - Log request: 0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:
2014-12-09 13:24:03,344 [Thread-12] DEBUG org.pidome.driver.driver.nativeMySensorsDriver14.NativeMySensorsDriver14 - Handling internal: 255;255;INTERNAL;3;
2014-12-09 13:24:04,122 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - GET /jsonrpc.json?rpc={%22jsonrpc%22:%20%222.0%22,%20%22method%22:%20%22HardwareService.getSoftwareDriverPresentation%22,%20%22params%22:%20{%22port%22:%22/dev/ttyUSB0%22}%20%22id%22:%22HardwareService.getSoftwareDriverPresentation%22}&=1418131338168 HTTP/1.1
2014-12-09 13:24:04,138 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Host: 192.168.1.6:8080
2014-12-09 13:24:04,141 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Connection: keep-alive
2014-12-09 13:24:04,148 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Accept: /
2014-12-09 13:24:04,151 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - X-Requested-With: XMLHttpRequest
2014-12-09 13:24:04,159 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36
2014-12-09 13:24:04,174 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Referer: http://192.168.1.6:8080/desktop/index.html
2014-12-09 13:24:04,181 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Accept-Encoding: gzip, deflate, sdch
2014-12-09 13:24:04,185 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Accept-Language: en-US,en;q=0.8
2014-12-09 13:24:04,198 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Cookie: key=3e148748-34e5-4ce6-8336-fcd5c8aaa0af
2014-12-09 13:24:04,203 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler -
2014-12-09 13:24:04,206 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Having header collection: {REQUEST=/jsonrpc.json, PLAINFILE=jsonrpc, METHOD=GET, HOST=192.168.1.6:8080, FILETYPE=json, QUERYSTRING=rpc={%22jsonrpc%22:%20%222.0%22,%20%22method%22:%20%22HardwareService.getSoftwareDriverPresentation%22,%20%22params%22:%20{%22port%22:%22/dev/ttyUSB0%22}%20%22id%22:%22HardwareService.getSoftwareDriverPresentation%22}&=1418131338168}
2014-12-09 13:24:04,214 [WEBCLIENT:192.168.1.24] DEBUG org.pidome.server.services.clients.http.HTTPClientHandler - 192.168.1.24 - GET: /jsonrpc.json
2014-12-09 13:24:04,243 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Complete constructed from header: {REQUEST=/jsonrpc.json, PLAINFILE=jsonrpc, METHOD=GET, HOST=192.168.1.6:8080, FILETYPE=json, QUERYSTRING=rpc={%22jsonrpc%22:%20%222.0%22,%20%22method%22:%20%22HardwareService.getSoftwareDriverPresentation%22,%20%22params%22:%20{%22port%22:%22/dev/ttyUSB0%22}%20%22id%22:%22HardwareService.getSoftwareDriverPresentation%22}&=1418131338168}
2014-12-09 13:24:04,249 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Get query data: {rpc={%22jsonrpc%22:%20%222.0%22,%20%22method%22:%20%22HardwareService.getSoftwareDriverPresentation%22,%20%22params%22:%20{%22port%22:%22/dev/ttyUSB0%22}%20%22id%22:%22HardwareService.getSoftwareDriverPresentation%22}, =1418131338168}
2014-12-09 13:24:04,268 [WEBCLIENT:192.168.1.24] DEBUG org.pidome.server.system.rpc.PidomeJSONRPC - JSON String to parse: {"jsonrpc": "2.0", "method": "HardwareService.getSoftwareDriverPresentation", "params": {"port":"/dev/ttyUSB0"} "id":"HardwareService.getSoftwareDriverPresentation"}
2014-12-09 13:24:04,282 [WEBCLIENT:192.168.1.24] DEBUG org.pidome.server.system.rpc.PidomeJSONRPC - Parsed JSON Object: {method=HardwareService.getSoftwareDriverPresentation, id=HardwareService.getSoftwareDriverPresentation, jsonrpc=2.0, params={port=/dev/ttyUSB0}}
2014-12-09 13:24:04,295 [WEBCLIENT:192.168.1.24] DEBUG org.pidome.server.system.rpc.PidomeJSONRPC - Set request id: HardwareService.getSoftwareDriverPresentation
2014-12-09 13:24:04,298 [WEBCLIENT:192.168.1.24] DEBUG org.pidome.server.system.rpc.AbstractRPCMethodExecutor - Searching named parameter set for getSoftwareDriverPresentation in HardwareService
2014-12-09 13:24:04,301 [WEBCLIENT:192.168.1.24] DEBUG org.pidome.server.system.rpc.AbstractRPCMethodExecutor - Found param key: port
2014-12-09 13:24:04,317 [WEBCLIENT:192.168.1.24] DEBUG org.pidome.server.system.rpc.AbstractRPCMethodExecutor - searching for getSoftwareDriverPresentation in HardwareService
2014-12-09 13:24:04,320 [WEBCLIENT:192.168.1.24] DEBUG org.pidome.server.system.rpc.AbstractRPCMethodExecutor - Declared params for getSoftwareDriverPresentation : [class java.lang.String]
2014-12-09 13:24:04,324 [WEBCLIENT:192.168.1.24] DEBUG org.pidome.server.system.rpc.AbstractRPCMethodExecutor - Passed in params for 'getSoftwareDriverPresentation': [/dev/ttyUSB0]
2014-12-09 13:24:04,334 [WEBCLIENT:192.168.1.24] DEBUG org.pidome.server.system.rpc.PidomeJSONRPC - Response data: {data={presentation=[{description=Information about the hardware used by this driver, title=Hardware link, content=[{label=Hardware, type=SIMPLE_NVP, content=Future Technology Devices International, Ltd, FT232 USB-Serial (UART) IC}, {label=Hardware port, type=SIMPLE_NVP, content=/dev/ttyUSB0}]}, {description=Gateway information, title=Gateway info, content=[{label=Version, type=SIMPLE_NVP, content=Waiting for gateway}, {label=Last receive time, type=SIMPLE_NVP, content=09-12-2014 14:24:03}, {label=Last send time, type=SIMPLE_NVP, content=09-12-2014 14:23:28}]}, {description=When a new node is added it will be displayed below. You will then have the option to add the node to the server. When in AUTO mode you can only add one sensor at a time. When using fixed addresses you can add multiple at the same time. Also, if you mix AUTO and fixed, always, but always add the fixed first otherwise the address allocations of the AUTO node can allocate a fixed one. It is required for the nodes to use presentation., title=New nodes presentation, content=[{label=Address request presentation, type=LIST_NVP, content=[]}, {label=Presentation, type=COMPLEX_NVP, content={255=[{custom_driver_function={identifier=newNodeRequest, function_label=Add sensor node, ADDRESS=2, function_id=customFunction}, 09-12-2014 14:24:03=New device: Possible new address: 2 if not occupied before adding (Restart node after assigning).}]}}]}, {description=Below is a list of last known 20 messages, title=Last known messages, content=[{label=Messages list, type=LIST_NVP, content=[{custom_driver_function={identifier=clearLogList, function_label=Clear log list, function_id=customFunction}}, {09-12-2014 14:24:03=0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:}, {09-12-2014 14:23:49=0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:}, {09-12-2014 14:23:15=Trying assigning address '2' to a new node}, {09-12-2014 14:23:15=0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:}, {09-12-2014 14:23:12=0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:}, {09-12-2014 14:23:10=0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:}, {09-12-2014 14:23:08=0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:}, {09-12-2014 14:23:04=0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:}, {09-12-2014 14:23:02=0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:}]}]}], driver=MySensors USB (serial) driver API 1.4, port=/dev/ttyUSB0, hardware=Future Technology Devices International, Ltd, FT232 USB-Serial (UART) IC}, success=true, message=}
2014-12-09 13:24:05,329 [Thread-12] TRACE org.pidome.server.connector.drivers.peripherals.hardware.PeripheralHardwareDriver - Data received from device: 65 byte(s)
2014-12-09 13:24:05,333 [Thread-12] TRACE org.pidome.driver.driver.nativeMySensorsDriver14.NativeMySensorsDriver14 - Received from hardware driver: 0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:
255;255;3;0;3;
2014-12-09 13:24:05,336 [Thread-12] DEBUG org.pidome.driver.driver.nativeMySensorsDriver14.NativeMySensorsDriver14 - Handling internal: 0;0;INTERNAL;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:
2014-12-09 13:24:05,339 [Thread-12] DEBUG org.pidome.driver.driver.nativeMySensorsDriver14.NativeMySensorsDriver14 - Log request: 0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:
2014-12-09 13:24:05,342 [Thread-12] DEBUG org.pidome.driver.driver.nativeMySensorsDriver14.NativeMySensorsDriver14 - Handling internal: 255;255;INTERNAL;3;
2014-12-09 13:24:07,337 [Thread-12] TRACE org.pidome.server.connector.drivers.peripherals.hardware.PeripheralHardwareDriver - Data received from device: 65 byte(s)
2014-12-09 13:24:07,340 [Thread-12] TRACE org.pidome.driver.driver.nativeMySensorsDriver14.NativeMySensorsDriver14 - Received from hardware driver: 0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:
255;255;3;0;3;
2014-12-09 13:24:07,343 [Thread-12] DEBUG org.pidome.driver.driver.nativeMySensorsDriver14.NativeMySensorsDriver14 - Handling internal: 0;0;INTERNAL;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:
2014-12-09 13:24:07,346 [Thread-12] DEBUG org.pidome.driver.driver.nativeMySensorsDriver14.NativeMySensorsDriver14 - Log request: 0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:
2014-12-09 13:24:07,350 [Thread-12] DEBUG org.pidome.driver.driver.nativeMySensorsDriver14.NativeMySensorsDriver14 - Handling internal: 255;255;INTERNAL;3;
2014-12-09 13:24:07,790 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - GET /jsonrpc.json?rpc={%22jsonrpc%22:%20%222.0%22,%20%22method%22:%20%22DeviceService.peripheralDeviceFunction%22,%20%22params%22:%20{%22peripheralport%22:%22/dev/ttyUSB0%22,%22params%22:{%22identifier%22:%22newNodeRequest%22,%22function_label%22:%22Add%20sensor%20node%22,%22ADDRESS%22:%222%22,%22function_id%22:%22customFunction%22}}%20%22id%22:%22DeviceService.peripheralDeviceFunction%22}&=1418131338169 HTTP/1.1
2014-12-09 13:24:07,795 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Host: 192.168.1.6:8080
2014-12-09 13:24:07,800 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Connection: keep-alive
2014-12-09 13:24:07,803 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Accept: /
2014-12-09 13:24:07,807 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - X-Requested-With: XMLHttpRequest
2014-12-09 13:24:07,812 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36
2014-12-09 13:24:07,815 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Referer: http://192.168.1.6:8080/desktop/index.html
2014-12-09 13:24:07,818 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Accept-Encoding: gzip, deflate, sdch
2014-12-09 13:24:07,822 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Accept-Language: en-US,en;q=0.8
2014-12-09 13:24:07,825 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Cookie: key=3e148748-34e5-4ce6-8336-fcd5c8aaa0af
2014-12-09 13:24:07,838 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler -
2014-12-09 13:24:07,841 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Having header collection: {REQUEST=/jsonrpc.json, PLAINFILE=jsonrpc, METHOD=GET, HOST=192.168.1.6:8080, FILETYPE=json, QUERYSTRING=rpc={%22jsonrpc%22:%20%222.0%22,%20%22method%22:%20%22DeviceService.peripheralDeviceFunction%22,%20%22params%22:%20{%22peripheralport%22:%22/dev/ttyUSB0%22,%22params%22:{%22identifier%22:%22newNodeRequest%22,%22function_label%22:%22Add%20sensor%20node%22,%22ADDRESS%22:%222%22,%22function_id%22:%22customFunction%22}}%20%22id%22:%22DeviceService.peripheralDeviceFunction%22}&=1418131338169}
2014-12-09 13:24:07,844 [WEBCLIENT:192.168.1.24] DEBUG org.pidome.server.services.clients.http.HTTPClientHandler - 192.168.1.24 - GET: /jsonrpc.json
2014-12-09 13:24:07,854 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Complete constructed from header: {REQUEST=/jsonrpc.json, PLAINFILE=jsonrpc, METHOD=GET, HOST=192.168.1.6:8080, FILETYPE=json, QUERYSTRING=rpc={%22jsonrpc%22:%20%222.0%22,%20%22method%22:%20%22DeviceService.peripheralDeviceFunction%22,%20%22params%22:%20{%22peripheralport%22:%22/dev/ttyUSB0%22,%22params%22:{%22identifier%22:%22newNodeRequest%22,%22function_label%22:%22Add%20sensor%20node%22,%22ADDRESS%22:%222%22,%22function_id%22:%22customFunction%22}}%20%22id%22:%22DeviceService.peripheralDeviceFunction%22}&=1418131338169}
2014-12-09 13:24:07,859 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Get query data: {rpc={%22jsonrpc%22:%20%222.0%22,%20%22method%22:%20%22DeviceService.peripheralDeviceFunction%22,%20%22params%22:%20{%22peripheralport%22:%22/dev/ttyUSB0%22,%22params%22:{%22identifier%22:%22newNodeRequest%22,%22function_label%22:%22Add%20sensor%20node%22,%22ADDRESS%22:%222%22,%22function_id%22:%22customFunction%22}}%20%22id%22:%22DeviceService.peripheralDeviceFunction%22}, =1418131338169}
2014-12-09 13:24:07,864 [WEBCLIENT:192.168.1.24] DEBUG org.pidome.server.system.rpc.PidomeJSONRPC - JSON String to parse: {"jsonrpc": "2.0", "method": "DeviceService.peripheralDeviceFunction", "params": {"peripheralport":"/dev/ttyUSB0","params":{"identifier":"newNodeRequest","function_label":"Add sensor node","ADDRESS":"2","function_id":"customFunction"}} "id":"DeviceService.peripheralDeviceFunction"}
2014-12-09 13:24:07,869 [WEBCLIENT:192.168.1.24] DEBUG org.pidome.server.system.rpc.PidomeJSONRPC - Parsed JSON Object: {method=DeviceService.peripheralDeviceFunction, id=DeviceService.peripheralDeviceFunction, jsonrpc=2.0, params={peripheralport=/dev/ttyUSB0, params={identifier=newNodeRequest, function_label=Add sensor node, ADDRESS=2, function_id=customFunction}}}
2014-12-09 13:24:07,872 [WEBCLIENT:192.168.1.24] DEBUG org.pidome.server.system.rpc.PidomeJSONRPC - Set request id: DeviceService.peripheralDeviceFunction
2014-12-09 13:24:07,875 [WEBCLIENT:192.168.1.24] DEBUG org.pidome.server.system.rpc.AbstractRPCMethodExecutor - Searching named parameter set for peripheralDeviceFunction in DeviceService
2014-12-09 13:24:07,878 [WEBCLIENT:192.168.1.24] DEBUG org.pidome.server.system.rpc.AbstractRPCMethodExecutor - Found param key: peripheralport
2014-12-09 13:24:07,881 [WEBCLIENT:192.168.1.24] DEBUG org.pidome.server.system.rpc.AbstractRPCMethodExecutor - Found param key: params
2014-12-09 13:24:07,884 [WEBCLIENT:192.168.1.24] DEBUG org.pidome.server.system.rpc.AbstractRPCMethodExecutor - searching for peripheralDeviceFunction in DeviceService
2014-12-09 13:24:07,887 [WEBCLIENT:192.168.1.24] DEBUG org.pidome.server.system.rpc.AbstractRPCMethodExecutor - Declared params for peripheralDeviceFunction : [class java.lang.String, interface java.util.Map]
2014-12-09 13:24:07,890 [WEBCLIENT:192.168.1.24] DEBUG org.pidome.server.system.rpc.AbstractRPCMethodExecutor - Passed in params for 'peripheralDeviceFunction': [/dev/ttyUSB0, {identifier=newNodeRequest, function_label=Add sensor node, ADDRESS=2, function_id=customFunction}]
2014-12-09 13:24:07,894 [WEBCLIENT:192.168.1.24] DEBUG org.pidome.driver.driver.nativeMySensorsDriver14.NativeMySensorsDriver14 - Sending internal message to device: '255;255;3;0;4;2'
2014-12-09 13:24:07,899 [pool-11-thread-1] DEBUG org.pidome.driver.driver.nativeMySensorsDriver14.NativeMySensorsDriver14 - sending: [B@17ba9e8
2014-12-09 13:24:07,902 [WEBCLIENT:192.168.1.24] DEBUG org.pidome.server.system.rpc.PidomeJSONRPC - Response data: {data=true, success=true, message=}
2014-12-09 13:24:08,026 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - GET /desktop/driversedit.html?requesttype=ajax&=1418131338170 HTTP/1.1
2014-12-09 13:24:08,029 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Host: 192.168.1.6:8080
2014-12-09 13:24:08,032 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Connection: keep-alive
2014-12-09 13:24:08,035 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Accept: text/html, /; q=0.01
2014-12-09 13:24:08,039 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - X-Requested-With: XMLHttpRequest
2014-12-09 13:24:08,046 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36
2014-12-09 13:24:08,049 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Referer: http://192.168.1.6:8080/desktop/index.html
2014-12-09 13:24:08,053 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Accept-Encoding: gzip, deflate, sdch
2014-12-09 13:24:08,056 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Accept-Language: en-US,en;q=0.8
2014-12-09 13:24:08,059 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Cookie: key=3e148748-34e5-4ce6-8336-fcd5c8aaa0af
2014-12-09 13:24:08,064 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler -
2014-12-09 13:24:08,067 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Having header collection: {REQUEST=/desktop/driversedit.html, PLAINFILE=desktop/driversedit, METHOD=GET, HOST=192.168.1.6:8080, FILETYPE=html, QUERYSTRING=requesttype=ajax&=1418131338170}
2014-12-09 13:24:08,070 [WEBCLIENT:192.168.1.24] DEBUG org.pidome.server.services.clients.http.HTTPClientHandler - 192.168.1.24 - GET: /desktop/driversedit.html
2014-12-09 13:24:08,073 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Complete constructed from header: {REQUEST=/desktop/driversedit.html, PLAINFILE=desktop/driversedit, METHOD=GET, HOST=192.168.1.6:8080, FILETYPE=html, QUERYSTRING=requesttype=ajax&_=1418131338170}
2014-12-09 13:24:08,080 [WEBCLIENT:192.168.1.24] TRACE org.pidome.server.services.clients.http.HTTPClientHandler - Get query data: {requesttype=ajax, _=1418131338170}
c2014-12-09 13:24:11,360 [Thread-12] TRACE org.pidome.server.connector.drivers.peripherals.hardware.PeripheralHardwareDriver - Data received from device: 65 byte(s)
2014-12-09 13:24:11,363 [Thread-12] TRACE org.pidome.driver.driver.nativeMySensorsDriver14.NativeMySensorsDriver14 - Received from hardware driver: 0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:
255;255;3;0;3;
2014-12-09 13:24:11,366 [Thread-12] DEBUG org.pidome.driver.driver.nativeMySensorsDriver14.NativeMySensorsDriver14 - Handling internal: 0;0;INTERNAL;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:
2014-12-09 13:24:11,369 [Thread-12] DEBUG org.pidome.driver.driver.nativeMySensorsDriver14.NativeMySensorsDriver14 - Log request: 0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:
2014-12-09 13:24:11,372 [Thread-12] DEBUG org.pidome.driver.driver.nativeMySensorsDriver14.NativeMySensorsDriver14 - Handling internal: 255;255;INTERNAL;3;

[John]

@tortoisedoc
This is very strange because if data was not able to be send, it would appear in the trace log right after:
2014-12-09 13:24:07,899 [pool-11-thread-1] DEBUG org.pidome.driver.driver.nativeMySensorsDriver14.NativeMySensorsDriver14 - sending: [B@17ba9e8

When you send "255;255;3;0;4;2\n" using term the node is assigned an id?

[tortoisedoc]

@John pardon my ignorance - can I just send by typing in miniterm or is there some special character sequence to be used before I can do so?
EDIT : Wrote a python program; data is going out (TX led on FTDI flashes right after writing) but has no effect. Funnily, miniterm does NOT see the written data passing by...

[John]

@tortoisedoc I have no experience with miniterm.... Does the TX led flash when you send press the button to assign a node id?

[tortoisedoc]

Ok, got ahold of some more components and am back up testing!

One question : is the value displayed in the drop-down box correct?
This appears once I try to connect the sensor.

[John]

@tortoisedoc Welcome back! Yes that is a temporary node address of a new node not having an address assigned. You shold be able to use the assign address button to assign an address to the node. After that is done restart the node so it can present itself properly.

[tortoisedoc]

@John Update:
two things.

1. the "Waiting for Gateway" is still here, even tho the gateway seems to be correctly receiving & sending data
   
2. it appears the bluetooth of my laptop might potentially be jamming with the sensor radio signal. Is this possible? Knowing the protocols share the same radio band (2.4 ghz)? Or am I hallucinating?

[John]

@tortoisedoc Yes bluetooth can certainly interfere also (it think around 70 channels) 2.4 ghz - 2.47 +/- band. Especially the older ones. As long as the driver is in waiting for gateway mode not all the data is being send out.

Also, do you have multiple nodes asking for an address at the same time? (because of the two seconds between requests) Please add one node at a time. 255 is a temporary address, if multiple nodes are requesting a node id multiple nodes will receive the same new address.

What the driver does is when there is a gateway ready message, it sends out a request for the version number. When this is received from the gateway the driver knows which version (future usage if/when a new protocol is implemented) of mysensors it must load.

Is it ok with you to test for me that receiving only the gateway message would be sufficient for the driver to enable all sending?

If possible. could you do the following for me?

1. Stop the server
2. Disconnect the gateway.
3. Start the server with "./server.sh trace".
4. When the server is started, connect the gateway.
5. Give it a couple of seconds and take a look at the driver page. After a maximum of let's say 7 seconds it should show the version number instead of "Waiting".
6. Let a single node ask for an address, and try to supply one.
7. After the above actions go to "Settings > Server settings" in the web interface and disable debug mode (this also disables trace mode only available via command line).
8. Please send the log file with your mysensors username so i know it's you to support.a.t.pidome.org

Trace mode logging provides me with the most information possible. If all of the above is included i can take a look at all these at the same time.

P.S. Sorry for the late response, wife's birthday today.

[tortoisedoc]

@John Okay. Seems we have something here now; see the attached log here:

appLog.txt

in particular :
2014-12-15 21:55:59,811 [USB-discovery] INFO org.pidome.server.system.hardware.drivers.Drivers - Something went wrong width the hardware: MEthod does not support NID to request driver.

[John]

@tortoisedoc Yeah... that one is an oldie and can be discarded, that one was for example going to be used with for example arduino serial devices. Responding to the NID request with a driver id can load the driver specific for the software written on the arduino. this function is disabled in the api for mysensors.

Ok, i'm seeing the next:

2014-12-15 21:58:34,527 [Thread-29] TRACE org.pidome.driver.driver.nativeMySensorsDriver14.NativeMySensorsDriver14 - Received from hardware driver: 0;0;3;0;14;Gateway startup complete.
2014-12-15 21:58:34,530 [Thread-29] DEBUG org.pidome.driver.driver.nativeMySensorsDriver14.NativeMySensorsDriver14 - Handling internal: 0;0;INTERNAL;14;Gateway startup complete.
2014-12-15 21:58:34,533 [Thread-29] DEBUG org.pidome.driver.driver.nativeMySensorsDriver14.NativeMySensorsDriver14 - Sending internal message to device: '0;0;3;0;2;Get Version'
2014-12-15 21:58:34,575 [pool-15-thread-1] DEBUG org.pidome.driver.driver.nativeMySensorsDriver14.NativeMySensorsDriver14 - sending: [B@13038e1

It is sended to the gateway, but there is no response. This routine has been working since implemented (almost the beginning when gateway ready was available).

@hek Am i missing something? Has the version info message been changed?

@tortoisedoc At moment of speaking i'm building a new test version on the build server (http://builder.pidome.org) which enables data when gateway ready arrives, but before it asks for a version. So you now should be able to send.

P.S. there now is a devices discovery page. devices with id appear here, devices without id (node id 255, so requesting one) still appear in the mysensors driver page. Also discovery is now enabled continuously. this is a quick build to get you going

[hek]

@John said:

Am i missing something? Has the version info message been changed?

Nope.

[Francois]

@John Hi my system was running fine till I what to add more sensor. Pidome do see the sensor but do not present the it in the "New nodes presentation" or the new "Discovered device". I can add the new nodes manually and that works. I am on version 508

here is info from the applog file:

[John]

@Francois Still busy with the centralized device discovery. The commit i did was to quickly have @tortoisedoc up and running to solve the issue he is having. it will be done today so devices will appear in the device discovery list.

Sorry for any inconvenience this commit has caused

[John]

@Francois Build server is busy with a quick fix for the MQTT gateway. Should be ready in a couple of minutes

[Francois]

@John download the ver509 and still doing the same thing.

[John]

@Francois Also not present in the discovery?

[Francois]

@John yes it is also not in discovery

[John]

@Francois Gimme half an hour

[EDIT] A bit longer, the devices proxy mapping (devices used in plugins) is misbehaving.[/EDIT]

[tortoisedoc]

@John thanks for the fix, will test it later today. Is the latest build still good to go?

[John]

@tortoisedoc Sending and receiving data is not influenced by the discovery utilities. It is possible new devices are not found (which have an ID assigned). But this should not be the case for nodes which are requesting an id (this is still handled by the driver).

The path to the hardware is now completely open after receiving of the gateway started message. I will in the meantime ask an other user if he has an issue with the request for the version number from the gateway

[John]

@Francois I have continued the normal development path of this feature. Otherwise i would be "hacking" the code and then remove this to be able to continue normally. I do have a quick build ready, could you check the latest build (510) if it is working for you?

[Francois]

@John This version (510) fix the issue and it did discovered the sensor. Thanks

[John]

@Francois Good!
@tortoisedoc Are you able to use the node assignment?

[Francois]

@John I must say that you product is getting better with every release. This new discovery process that you now add is making things ever easier to add sensors to the system Thanks for all the hard work that you are putting into this project. I real appreciate this. Keep up the good work. You product just work and I don't have to worries about it.

[John]

@Francois Thanks for your kind words! Too bad you didn't download the release on the builder this evening, you have fallen in a test sequence ;).

When the routine is completely implemented i will post a follow up on this feature.

[Francois]

@John I never skip an release the moment there is new release I installed.

[tortoisedoc]

@John said:

@tortoisedoc Are you able to use the node assignment?

Unfortunately not.

See here: appLog.txt
At this point, im starting to suspect about the PI. The miniterm shows correctly the gateway startup tho.

[ceburge]

Getting this error with the 510 build.

[John]

@tortoisedoc The only thing i see is a gateway ready message, i do not see any node presenting or asking for a node address. I suspect that this information is also not available in miniterm. If it is, you have to try again without miniterm cause this then is interfering.

[John]

@ceburge Is this a fresh install or an update? If this is an update please clear the browser cache and re-open the browser

[ceburge]

@John said:

@ceburge Is this a fresh install or an update? If this is an update please clear the browser cache and re-open the browser

It was indeed an update. The clearing of the browser cache did the trick. Thanks alot.
By the way. Love your work you are doing with PiDome. It is user friendly and something that most people can funtion in. Keep up
the good work.

[John]

@ceburge Thanks! And that's exactly the thought behind the project (not in the beginning because it was a personal thingy, but has grown in to), try to create something most people would be able to use. It still needs a lot of work, but it's getting there. We have planned very exciting stuff!

PiDome relies heavily on the browser cache, one of the reasons why it responds relatively quick in most situations. So if there is any error with title "Interface error", clear the cache ;).

Cheers!

P.S. the reason for this error is due to the fact the messaging has been optimized, where possible device values which can be updated are now in one single message instead of four (if a device has four controls and/or data fields).

[tortoisedoc]

@John said:

@tortoisedoc The only thing i see is a gateway ready message, i do not see any node presenting or asking for a node address. I suspect that this information is also not available in miniterm. If it is, you have to try again without miniterm cause this then is interfering.

@John Ok, here more logging:
appLog.txt

There is actually data coming in - but the visual part is empty both in the driver's section as well as the "new" section for non-discovered devices.

PS I tested this in Chrome as well as in Firefox;

and the result is empty :

[ceburge]

I believe there may be something wrong with the serial driver now. It was working like a charm in a previous build. Not sure what that build was though. I decided to update to the 510 version build due to the fact that I could never get my MQTT Gateway to auto discover devices. However I decided to go ahead and test what I already had working in the new build and it doesn't function correctly.

I am including an image of the drivers page I now see when using a serial connection. App log i there to if you want to look at it

appLog.txt

[John]

@tortoisedoc and @ceburge The builds on the build server are still test builds regarding discovery and driver web front end API. They are getting more stable but is still a work in progress. The builds which are following up are tests to test the progress of the current development roadmap regarding these.

This is a known issue and am working on it while the development progresses.

Excuse for any inconvenience, hope to have this functionality done asap.

P.S. I'm looking into the possibility to also have the node address requests being passed to the discovery collection page, all though it is a complete different internal process trying to make it coherent.

[tortoisedoc]

@John said:

@tortoisedoc and @ceburge The builds on the build server are still test builds regarding discovery and driver web front end API. They are getting more stable but is still a work in progress. The builds which are following up are tests to test the progress of the current development roadmap regarding these.

This is a known issue and am working on it while the development progresses.

Excuse for any inconvenience, hope to have this functionality done asap.

P.S. I'm looking into the possibility to also have the node address requests being passed to the discovery collection page, all though it is a complete different internal process trying to make it coherent.

Sounds great !
Thank you for your efforts!

[John]

@tortoisedoc It has to work correctly, so will continue on it until it does.

Today there will be sequential builds which will introduce new discovery options. The new method will also include discovery of mysensors devices which do not have an address assigned yet.

Build number 511 (just build) will/should include the visibility of these nodes, but can not be added yet. It is safe to use build 511 as long as predefined node addresses are used. This will be included in build 512 (which i hope will be available on a couple of hours).

[John]

Build 513 is out there (it includes the inclusion mode available for testing).

Please be notified about the fact that this build has to be tested. More builds can become available in a rapid tempo, When the MySensors transition to the new discovery method is complete i will post it here.

[ceburge]

Maybe I'm not understanding how this works correctly. I have used the alpha build for a while now and it just worked flawlessly with an MySensors serial gateway. Was this part re-constructed in the latest build? My device shows up in the peripherals page and I can set the connection then save set and start. However when I go to the drivers page I see my device but when I click on it to view device info, all I get is a blank page. I can't get any of the last 3 builds to recognize that there is even a gateway connected in the drivers menu.

[John]

@ceburge Yes, it is being overhauled. The discovery of devices is being moved to one single page. All drivers which are able to report new devices will be showing these device in this new page. I;m doing this for a couple of reasons:

1. To let a driver show a device you have to program this separately for every driver. Now a driver just has to provide a couple of details to a centralized environment which will take care of all the visuals and possible options. Creating this takes a couple of days, but results in massive winnings of time in future developments,
2. If there is one page, one single command to retrieve discovered devices i can finally incorporate this functionality in clients. In other words you do not need the web interface to add devices. Just take your tablet or phone (client is in development),
3. It saves server memory (currently this function already saved 2 MB ram without devices in the discovery table),
4. It splits functionality and makes the driver page only necessary when there is need for debugging, or driver settings. In the future you can assign user rights, yes add devices, no driver details.
5. It now is possible to inform users when a new device is found on the fly without refreshing pages, displays or other visual presentations enhancing experience.
6. I'm busy finalizing the programmers API, this means quick programming work needs to become stable en reliable. Using this method will introduce more reliability when it is done.

It is correct that in the current hot-fix/hot-off the press features things can go wrong. Keep in mind that the build server is for creating a quick build for testing! it can contain fixes, but also fails. The regular download page contains the download which is the most stable hot-build which got more intensive testing. This will stay like this until the moment the first Beta/Release Candidates comes out which will be the most intensive tested ones.

The gateway connected page will come back!

[ceburge]

Thanks for explaining that. That helped me understand a bit more about what is going on. One more question! At what point does the development build become Alpha if it does? Also how would one know if the Alpha build has changed to a different version without installing it? Sorry it was actually two!

[John]

@ceburge No problem!

Anwer 1:
The (lets call it "main") alpha build is at the regular download page on the main website, Quite often development builds are supplied with open source applications. And that is what is available on the build server. These are builds created while developing, resulting in often refreshing. So if you are playing around with the software, do not care possible failures, are willing to spam me with error's you encounter, willing to help to test, or eager for a specific functionality, please use the build server downloads.

The development builds are always alpha, it continuously changes etc.... At a specific moment i'm done with a particular function or change set. If the testers are reasonable happy with what is available on the build server, it is put on the download page as the main alpha. Which also is the recommended download.

To answer question 2:
I wished i could type what i have written in my notebook as todo's.

a: At first, it is planned that if an user allows the server to connect to the internet (not he plugins etc.. but the server itself). There then is a possibility to get notified when a new version is available and it will be automated. But this is part of a bigger plan.

b: If you see a build version online for example the current build is: 0.1-snapshot-2014-12-17.514 the build is 514. In the web interface you can check which version you now have by clicking on "Server Status". The build number is on the top left.

If you are just installing out of the blue:
When you start the server for example with server.sh use the command: './server.sh ; tail -f logs/system/appLog.txt" When the server is starting you will see the log file being filled, one of the first lines is: "Starting server with build: 514 on platform: Linux (arm)". While the server boots and it is updating it's internals you will see something like "Updating database from [number] to [number]".

So these a,b and c are the only way to detect the version number when you are installing, or want to install.

So, the development of PiDome follows a quite strict development roadmap where the builds on the build server are adhoc and on the regular page are "stable enough"to provide as download.

I hope to make things more clearer for you.

Cheers!

[John]

@ceburge, @tortoisedoc

The driver presentation has been enabled again from build 516 which is now available, so you should be able to see the driver/gateway status again (clear browser cache). This build also has inclusion mode support to comply with the MySensors Serial API (this should be tested).

To view if inclusion mode works, open the admin page in the browser, press the inclusion button at the hardware gateway. You should see the message passing by that device discovery is enabled for mysensors.

You can also enable the inclusion mode from the web browser by going to the page "Device/Drivers management > Device discovery" select the MySensors serial driver, and press "Enable discovery".

You can double check if discovery is running, every driver in the dropdown list will have an icon. A spinning icon means discovery is enabled. A non spinning icon with a red line through it means discovery is disabled. Every time a node is discovered the list on the "Device discovery" page is automatically refreshed, no need to refresh the page. Also you will receive a notification on the right bottom part of the web interface that a new device has been discovered.

[tortoisedoc]

@John I think I just found something interesting here, which might actually match my case:

[quote]
I've tried two different pro mini 3,3v boards, and the SerialGateway does not respond to serial commands on them. I expect 0;0;4;4; to reply the firmware version of the serial gateway. And it works fine on non-3,3V-pro-mini. The vera lua script is doing the same on startup:
[/quote]

from :

http://forum.mysensors.org/topic/66/unable-to-use-the-serialgateway-code/4

I will dig a little into this before performing more tests.

[ceburge]

Tested build 517 with serial gateway. Everything with the device discovery did as expected. Just can't beat the dynamics of this! I'm not sure if this has anything to do with the build or maybe something else, but I am using the Relay Actuator sketch to test with. Everything seems to work fine with the exception of when the light is toggled with the button. The status of Off and On in the control view never gets updated. I had this problem with an earlier build I think it was Alpha build 493, but with 493 I could turn the relay On from the controller and then toggle the push button to turn it Off and the controller would update to Off but never would to On now it's not doing either one. Do you have any ideas why? I see the serial monitor sending to the gateway the update with an OK but never see it get passed to the controller inside the driver page.

[John]

@ceburge Good to hear that the disocvery does what it has to do.

Reagrding the toggle button, this one listens very carefully, could you send a printscreen of the control details of this button in the device editor to support@pidome.org?

@tortoisedoc Please let me know your findings! I must day that every test i did when i had the gateway running (before it became a IR relay) was always with the nano.

[tortoisedoc]

@John Okay! Making progress here; after digging and digging, it appears my FTDI module is funky; as in, 115200 Baud seem to somehow be a problem for it.
I made a quick test sketch where arduino increases a counter and writes out the current value, and i have the possibility to reset the value (between 1 and 9). Well, it works properly only up to 57600 baud. Weird. I will test a version of the mysensors @ 57600 Baud now.

EDIT AND IT WORKS! COME ON :D!

This is interesting indeed. I wonder how it comes baud rate 115k fails the FTDI (note : both on PC AND RPi)...

[John]

@tortoisedoc Good that it's working, please take a look at this page regarding higher speed, not much text, but explaines a lot: http://forum.arduino.cc/index.php?topic=26044.0 It could be an issue more often with for example cheap clones?

[edit]Self note: change the text at new nodes presentation, it does not appear on the driver page anymore[/edit]

[tortoisedoc]

@John both board and FTDI are from sparkfun...I believe that is the official maker? But yes, this is exactly the same type of problem I have.

[John]

@tortoisedoc The solution then would be build one with a crystal, or keep on using the lower speed. I personally had no problems with data running at 57k

[tortoisedoc]

@John said:

@tortoisedoc The solution then would be build one with a crystal, or keep on using the lower speed. I personally had no problems with data running at 57k

@John I will definietly keep the 57 K ; it should be enough as the data transfered is minimal. I plan to add another 5 sensors at least, but I believe it should be ok.

[ricardot]

Hello John

When I try to save a trigger I am getting this error:

Message:
java.lang.Integer cannot be cast to java.lang.Float

Trace:
java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Float\n at org.pidome.server.services.triggerservice.rules.RuleIfNumberFloat.equalsTo(RuleIfNumberFloat.java:74)\n at org.pidome.server.services.triggerservice.rules.RuleIf.equalsTo(RuleIf.java:141)\n at org.pidome.server.services.triggerservice.rules.RuleIf.run(RuleIf.java:113)\n at org.pidome.server.services.triggerservice.rules.RuleSubject.run(RuleSubject.java:92)\n at org.pidome.server.services.triggerservice.TriggerEvent.createRuleSubjects(TriggerEvent.java:353)\n at org.pidome.server.services.triggerservice.TriggerEvent.createSimpleRuleSet(TriggerEvent.java:277)\n at org.pidome.server.services.triggerservice.TriggerEvent.createRulesetFromJSON(TriggerEvent.java:225)\n at org.pidome.server.services.triggerservice.TriggerEvent.(TriggerEvent.java:211)\n at org.pidome.server.services.triggerservice.TriggerService.saveTrigger(TriggerService.java:229)\n at org.pidome.server.system.rpc.TriggerServiceJSONRPCWrapper.saveTrigger(TriggerServiceJSONRPCWrapper.java:240)\n at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)\n at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)\n at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)\n at java.lang.reflect.Method.invoke(Method.java:483)\n at org.pidome.server.system.rpc.AbstractRPCMethodExecutor.execMethod(AbstractRPCMethodExecutor.java:166)\n at org.pidome.server.system.rpc.AbstractRPCMethodExecutor.execMethod(AbstractRPCMethodExecutor.java:121)\n at org.pidome.server.system.rpc.PidomeJSONRPC.handleRequest(PidomeJSONRPC.java:358)\n at org.pidome.server.system.rpc.PidomeJSONRPC.handle(PidomeJSONRPC.java:245)\n at org.pidome.server.system.webservice.webclient.Webclient_jsonrpc.collect(Webclient_jsonrpc.java:55)\n at org.pidome.server.services.clients.http.HTTPClientHandler.run(HTTPClientHandler.java:186)\n

Am I doing anything wrong? Thanks!