PiDome Domotica/Home Automation

[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!

[ericvdb]

Hi John,

I'm trying to create a custom device that sends RF codes to a RF433 Mhz node, but I can't seem to send the additional fields I added to the device.

The additional fields:

Am I trying something here that is simply not possible?

I want to add that device over and over with different House- and Device Codes:

So in the end i need to send 4;3;1;0;2;3A1 to turn a light on at Housecode 3 and Devicecode A (and 1 is turn on, 0 is turn off)
Is this currently possible?

Many thanks and keep up the good work, really love PiDome.

[John]

@ricardot
Hard to see from only the stack trace. Is it possible that you send me a screenshot of how you setup the trigger and send this to support@pidome.org? The trigger system has become quite mature, so the message you have posted should not occur in any case. Need to take a close look into it.

[John]

@ericvdb said:
Hi eric,

try to set the on command to 3A1 and the off command to 3A0 in the V_LIGHT toggle control. I know this is not what you want because this means you have to create a device for every address. And with flexible addresses you want to use the options so users can enter them.

You are using the device editor the correct way, it currently only is not implemented yet. There is a task on my to-do list to take a look on how common fields for controls can use the options created in the editor.

You know what, send an email to support@pidome.org with some of your device details, and I will come up with something. (If the programming API was ready i could have given some guidelines, but unfortunately it is not yet).

P.S. it is 00:46 here, so expect an answer tomorrow ;).

[edit]typo's[/edit]

[ricardot]

I also Install the android client, but I can't make it works. I receive a login error: Could not connect/login: Authentication needs to be verified (202)

But the client never ask me for a username and password.

[John]

@ricardot Is not needed. On the server create an user. Then connect with the client to the server. On the page Connected clients you will see your android device. Click on it, select the user you just created and confirm your selection. The android client receives the confirmation and will continu starting. This device is now bound to this user.

[jonnyfishman]

Hi John,

Happy Xmas and enjoying the new updates.

I can't seem to get the 'Send data to an url' tab to work in automation anymore. Is this a bug or do I need to change the way it functions (it was working in an earlier version with the same settings).

Jon

[John]

@jonnyfishman Thnx! Hope you enjoyed Christmas as much as i did.

There has been some streamlining done of code. This is the second report and i'm currently looking into it.

If possible, Stop the server and start it with "./server.sh trace". Keep it running for a couple of minutes (so it can do a couple of http send commands). then go to "Server settings" in the web interface and turn of debug logging (bot trace and debug are turned of with this). Send me the file "logs/system/appLog.txt" to support@pidome.org with a reference to this post.

Cheers,
John.

[EDIT]The other reported issue was a timeout on the remote host. Please take a look in the log file if this is also the case for you[/edit]

[ricardot]

John,

I would like to know what I need to do to create a rule to turn on an off a mysensors relay in a specific time of the day. And also If is possible Pidome to send me a email when it happens.

Thanks!

[John]

@ricardot At the automation rules create a new rule:

• At the left side you can select rules logic and select an if block. put this on the field
• Click on Time/Date/Dayparts on the left and select the block when time is, and fill in the time.
• Click on devices on the left and select your MySensors device and choose the action.
• Give your rule a name and description.

Currently there is no option to send an email but there are messaging (which send messages to clients, pushbullet and sms. Email will follow asap.

P.S. Note to all: Will be on leave until the 5th of januari next year (sounds long...). There will be support but this is at a minimal level.

[jonnyfishman]

Hi John,

Checked the appLog.txt and the request was going through (it received a HTTP 200 code). The problem was the automation rule. It was no longer happy with having a variable as a parameter, I had to change it back to a string for it to work [examples below]?
**ricardot **- This might also work for you. I'm using the 'URL hits' under 'miscellaneous' to email myself using the code below. Essentially it sends out a form to a waiting page on my website that automatically emails me when it receives the correct data, using the PHP mail function.

This works.

This doesn't

[John]

@jonnyfishman
Sorry for the late response, the holidays consumed us all quite a lot, and i'm still on a sort of holiday leave, Could you send me the log, i'm interested in why the variable is not handled.

Cheer,
John.

P.S. Happy new year!

[jonnyfishman]

Happy new year to you,

I've attached the appLog. Relevant lines appear to be 2495 and 1555.
I recreated the error several times to make it show up. At 2495 the variable is listed as null, whereas at 1555 the variable is passing what it should.

appLog.txt

Thanks,
Jon

[John]

@jonnyfishman Currently i'm not in the position to check it. I'm back at 5th of January. I will pick it up that day.

[John]

@jonnyfishman

I have updated the latest build on the build server. It looked like that the fallback (create a string type variable) did not set the variable value. This should now be fixed.

Cheers!

[John]

We now have a forum available, so if you have questions which are not related to MySensors these can be posted over there. This way this forum can be kept clean and dedicated to mysensors ;).

Cheers!

[dafoink]

@John I am new to all of this. I am an Arduino programmer. but this is a first to communicate with a controller. Is there a simple "ping/pong" example. where a device is created in PiDome that is a basic switch or trigger that then just sends a message to an Arduino. and then the Arduino sketch sends back a known value that we can then review in PiDome?

brian

[John]

@dafoink
Communication with a plain Arduino using USB it currently needs to be programmed in the server. Methods to do things like ping/pong will be eventually possible using the web interface.

[John]

I have added colorpicker support to the serial version of MySensors, When it has proven itself it will be added to the MQTT version as wel.

I have tested this with one user and he has confirmed it working.

It works as follows:
Add a color picker to the controls as you would do with any other control (data/toggle button/etc..).

There are three color modes, these are only used for how the color picker behaves in the interfaces. These are:

• RGB - Shows three sliders: red, green and blue, use these to choose a color.
• HSL - Shows three sliders: Hue, Saturation and lightness. Different with the RGB is that you can turn lightness to 0 ti simulate lights off.
• CIE (Lch)- Shows three sliders: Lightness, hue and chroma, use this with calibrated fixtures, it can be quite off.

Colors are send as RGB string to nodes without the number sign (#). I recommend using V_VAR(1-5) as the variable type as it is custom data.

You also need a minimum of one button added in the colorpicker settings window. This will add a button so the selected color in the color picker will actually be send. The value is not important but must be filled in.

Below an screenshot as an example of how to set up:

http://s9.postimg.org/k1qvy23f3/Capture1.jpg

Code for retrieving the r,g and b from the send string is available in this post: http://forum.mysensors.org/topic/816/send-color-data-to-sensors/14
I personally have not tested the code (currently occupied hardware).

[John]

This is an important message for all MySensors PiDome users.

Oracle has released an update for Java on ARM. This update is numbered: Java 8 Update 33. But this release has features removed which the alpha builds are utilizing. I was busy with a feature to supply a graphical user interface embedded in the server so the Raspberry Pi could be used as server and client at the same time (slimmed down version).

Because Oracle decided to remove JavaFX from this update, and i have JavaFX test code within the server, this update will completely $#%$ PiDome so it won't run correctly, or wont run at all.

I have to remove all JavaFX related code from the server before you guys can upgrade to the new Java Release. I'm sorry for any inconvenience if you really need to upgrade Java.

I will place a message in this thread when i have fixed it.

[John]

Have been quite busy the last two days to remove any possibility to run the server with an embedded client. So you are save to update again. The latest version with the "fixes" is available on http://builder.pidome.org/job/PiDome Server platform snapshot build/lastSuccessfulBuild/ .

All though all dependencies have been removed it could show a quirk here and there, but will not influence server inner workings.

[bomber]

Hi John!

Can You tell, is it possible to show battery level and sketch name and version in PiDome? How to describe this information under custom device?

Thanks in advance

Vj

[John]

Hi @bomber

Battery status can be done this way:

1. 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)).
2. 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.
3. 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.

Sketch name and version is not available, let me see how quick this can be added (if it is a quick add will do it immediately, otherwise it get's a position on my to do list, recent (unfortunate) developments are requiring a lot of my time).

Cheers,

[John]

@bomber

I_SKETCH_NAME and I_SKETCH_VERSION have been added, only currently they only appear after a device has been added and is restart (during presentation and the device is known in the server).

I currently do not have the time to have a persistent solution where the values are remembered during discovery (inclusion). Group id for both is also "INTERNAL" and the control id's must be I_SKETCH_NAME or I_SKETCH_VERSION. The data type is String.

P.S. it is currently builing on the build server, give it a couple of minutes.

[AndrewB]

Hi John,

I'm pretty new to PiDome and MySensors but I've been gradually figuring things out. However I can't get the battery information to display in PiDome. I followed your instructions you gave above but it never receives the information even though I can see it being sent via the com port on my pc. Has the method of receiving the battery information changed in the last 7 months since you posted this?

[John]

Hi @AndrewB

As far as i'm concerned the methods for displaying battery status have not been changed. it could have been changed between some days seven months ago.

Are you using group id "INTERNAL" and control id "I_BATTERY_LEVEL" ?

[AndrewB]

Yes I am. I have checked and double checked. I am using the default BatteryPoweredSensor sketch that is included in the MySensors library.

[John]

It currently is quite late i will test this tomorrow as i also have some resource available then. I have to get some hardware together, if i find everything quick will test it in a moment for you. I need some info from you though:

What is your current build number being used (see server settings page)?
What is the mysensors library version you are using, 1.4 or 1.5?

Cheers!

[AndrewB]

Thanks for doing that! No rush though.

I am using build number 0.1-SNAPSHOT-2015-08-25.528

and Mysensors ver 1.5

[John]

Oh dear, we are already at build 540 for the server with full platform build at: 0.1-snapshot-2015-09-05.746. The next server build version will probably stay at 540 but the platform number will become 747. I will notify here when there is an update.

Build 747 will require you to update the android, desktop or raspberry pi client if in use, so be prepared

Cheers.

[EDIT]
I can confirm the battery level is not handled correctly. I'm on it now. The issue is that the data type is not handled correctly. If you would have used something else then float it would not work. I'm doing an explicit cast to float and did not respect the set type as set in the device editor. Currently testing and updating.
[/EDIT]

[John]

There currently is a new version of the server being built on the build server. The location is: http://builder.pidome.org/view/Snapshot builds/

When it's done you can click 0.1-snapshot-2015-09-06.747 and download the server. On the pi stop the server, overwrite files, and start it again. Don't worry, important data will not be overwritten (as with any update)

You can see it is done when on the left side there are no active jobs being displayed.

Let me know if it has been solved for you.

[AndrewB]

Thanks for the quick responses and update!

I downloaded and installed the new version on my pi, confirmed it was the correct version inside of pidome, however it is still not working.

[John]

Could you make a screenshot of your created device it's

• Group control details
• Control details

And check in the file logs/system/appLog.txt if you got messages mentioning mysensors? (quite at the end, you can do a "tail-f log/system/appLog.txt -n 200" in putty "ctrl+c" to stop it, select lines, click (copy) and paste them)

[AndrewB]

I currently have debug enabled, will that make a difference on what you want from the log file?

[John]

Well that would give a big amount of data, and it definitely will help... If you do not mind i will send my email address using chat so i can send you files if needed what could help in solving this quicker.

[AndrewB]

Sure! No problem!

[John]

Send via chat

[John]

With help from @AndrewB The issue has been solved.

The battery level via the MQTT gateway seems to need some extra attention as it is broadcasted in an unexpected mqtt path.

to show battery level using mqtt please use group id "255" and control id "V_"

Cheers!

[bramasa]

@John
Hi John,

I also stuck on the same problem as Eric has described. His post is quite a long time ago, so I don't know, if there is a solution now. The point is that I want not only transfer a status on/off to the mysensor node but the house and device code for the RF switches. I tried to do this as you have answered but if i look in the log file it say only true or false as payload to the sensor.

Is this a limitation of using V_LIGHT (allowing only boolean coded payload)? But I also tried to use other V_* like V_IR_SEND, it was the same result.

Thanks in advance.

[John]

Sorry for the late response, have you tried to change the datatype to string with the codes as the values?

[bramasa]

Hi John,
appLog.txt
I also tried using datatype string but it doesen't work. Meanwhile I have studies the log files more detailed and found the following behavior:

• when defining the device skeletal and when updating the derived device (first approx. 25 lines in the log file V_STATUS is declared as string with values 51 resp. 52 as specified in the web interface. The entity is "Modul 433 MHz".

• Later on, when using the toggle switch in the web interface the value has changed in the decription in the log file (see line 164 or 185) value has been changed to on/off. With this definition it seem that the mysensors-Plugin is feeded has been changed from the specified values.

My conclusion is that the change is taking place somewhere outside the mysensors-plugin.

By the way, if I change the type to string do I have to use quotation marks in the web interface?

Thanks a lot for your support.

Martin