Posts made by John

Oh wow, it has been a while since i was last here, and i truly apologize for this but it has been a very, very, very busy year for me.
New job, writing a technical book, attending conferences, etc.. etc... it does not mean the project was at a standstill but has been progressing slower then anticipated. We have been expanding our team with a real UX and UI designer and will provide the PiDome backend engine to be used in a charity program.
We have also been upgrading our support system to Jira and we have started to follow a more agile approach in the continuous development. The web interface has been cleaned up, our android app is finally in the play store (as alpha so you must be a tester), next to the android app there is an embedded (raspi), magic mirror and photo frame app in development. And not to forget, we also started with IOS.

A while ago I gave the community time to come up with feature requests in a couple weeks period. I'm currently in process of implementing all these features and mature existing functionalities (like proper http2 support and move to secure only connections).

With all the above i wanted to let the mysensors community know that you have not been forgotten. A big portion from the PiDome user base was/is coming originated from the mysensors community whom should not be let down as the dedication which is being put into it is awesome! I will soon start working towards supporting mysensors 2.0. I have to be honest, it will not be immediately, but it will happen ASAP.

Cheers,
John.

I should have paid better attention because i would have definitely joined!

But to possible make it up a little bit, I will be present at the Eindhoven mini maker fair this weekend (10th and 11th) in case some want to shake hands.

Cheers,
John.

Yes, but this is mainly visuals, the routines all stay the same.

Cheers!

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

@bjornhallberg Thanks for the change!

P.S. i recently also added support for local /dev/tty* serial ports which weans that also the GPIO gateway solution is available (http://forum.mysensors.org/topic/2389/added-support-for-local-mysensors-rpi-direct-radio-connection). I know changes are a bit scattered but also is my implementation schedule, sorry ;).

Cheers!

All though this topic is related to the development branch, has the topic structure been fixed (except for prefix)?

In my opinion this would be fritzing http://fritzing.org/home/

Maybe handy to post a schematic of your wiring.

Recently i added support for custom created serial ports. This also means support for the local MySensors RPI<->NRF connection using the RPI GPIO pins is supported. I have just tested it and can confirm it working, follow the screenshots below as a small howto for the connection.

First, get the nrf working on the Raspberry Pi and make sure it talks to nodes.

1. Add the custom port
   As PiDome works with libudev and is triggered an hardware added/disconnected signalling it also means that if you add a custom port (for example with /dev/ttyMySensorsGateway) which does not trigger hardware added signalling, the port is not recognized.
   So an option is added to PiDome to add a custom serial port.
   Go to Management > Peripherals
   

2. Click on the "Add custom port" button
   The server will traverse the /dev/ directory and look for /dev/tty* ports and show them in the drop down menu. Here you can select the MySensors local serial port and give it a name. It's like naming your own hardware
   

3. Click create Hardware (Future naming will be Create port link)
   The port reference is now created, it will get a yellow label with the text "Attentions/Settings" Which is normal as you need to supply connection settings. If /dev/ttyMySensorsGateway would be triggered automatically you step 1 and 2 where not needed but you would also get the yellow label.
   

4. Set your connection settings
   Click on the newly added MySensors port you have created with the yellow label, a popup with connection settings will appear. Set the connection settings as shown in the screenshot with of course the created port. And yes select the USB driver as it is compatible.
   

5. Press Set and start
   If all goes well you will see the same as below with a green success label.
   

6. Check the settings
   Not really an added step but handy to know you can check the connect settings by clicking on added mysensors driver. You will see something like shown below. P.S. This window is also used to disconnect the hardware. Just in case you had some wrong settings you can click disconnect and reconnect later on.
   

7. Check stuff works
   Got to Management > Drivers and click on the MySensors driver. When you see "Gateway Startup complete" You have made a successful connection. If not check your wiring and/or connection settings.
   

I have tested it with the PingPong sketch and the screenshot below conforms it working

There are two things:

1. It is possible you will be seeing that the server load is 100% as a message in the web interface. This is due to the /dev/mysensorsgateway. When you connect the server with serial settings the load will lower.
2. PiDome only works with the gateway when the gateway works. So if there is any issue, first check the gateway unless you have seen gateway started.

Cheers!

P.S. PiDome will remember the custom added port and the configuration is written to config/hardconf/cust_serial/. Normally the server would remove these links from it's configuration of they are non-existing. So when you reboot your PI the port reference still exists.

If you want it all to go automatically after reboot make sure the pigateway is started before PiDome is started. Otherwise you have to set the connection settings manually again.

Hi @bjornhallberg,

We have been updating our website from wordpress to a self hosted platform on http://pidome.org, This means the url pidome.wordpress.com will be obsoleted and http://pidome.org is the new location.

Could you update the url?

Thanks in advance and cheers,
John.

Now that the website is done for 90% (except from the mentioned above)

I will be focusing on techniques and the other parts of the software again. zwave will be added soon. I will update the features technologies page

The last couple of weeks have been a bit quiet from my side. And the reason is that I was busy with a somewhat updated version of the PiDome website.

Today i'm proud to announce the new website has launched!

I have left the http://pidome.wordpress.com blog styled web pages and the website is now running with a self designed framework. A lot of changes have been made with the most important ones the manual and the API pages.

The new URL for the website is now also simple http://pidome.org which is more recognizable.

This is the first version of the website release and i have some extra plans for in the future which consists of the following:

• A Working login,
• One login for forum, articles posts and an user dashboard,
• An user dashboard where an user can track his own to the community published device setups.

The Dashboard can certainly be interesting for MySensors users as you then will be able to share your custom created MySensor node to the PiDome community. Meaning that you post your MySensors code in the MySensors forum and when you have created this device structure on The PiDome server you will able to share this device structure from the server's web interface.

I Hope the new website will make it easier to find the MySensors support page (which needs an update, but will do this after the weekend)

URL's:
The PiDome website: http://pidome.org
Finally meet the team behind PiDome: http://pidome.org/pidome-team/

The New website announcement page: http://pidome.org/info/blog-news/2015/11/5/welcome-to-our-brand-new-pidome.org.html

And last but least, the most important page
The MySensors manual page: http://pidome.org/support/manual/devices/supported-devices/mysensors-devices.html

Cheers,
John.

@blacey No problem! As long it is possible to have all the IR codes be able to store on the server i'm very interested Take all the time you need to get it to your requirements

Yep, that's correct, to make sure the correct interface is loaded (serial/hid/etc..). If you would get it to trigger udev with a serial description it should catch it.

Nonetheless in about a week or two, three i think the fixed udev triggered mechanism will be supplemented with an user selectable list of available ports as i'm quite interested in this mockup.

This looks really cool! What is PiDome's role in this picture?

I think this was meant for @John-Connolly ?

@hek @awi
The only thing i can think of at the moment is to have a message amount + sequence. When sequence is out of order throw away the message. and disregard the following message

Or start + termination bytes implemented. This byte could identify being a multi message or a single message. A single message has the termination byte set. A multi message starts with a start byte and the last with the termination byte. Problem is lost messages creates strange texts missing pieces.

Both methods will be able to determine new message because of the "start" byte. But the second proposal would be more error prone because if a message with a start bit is missed it would keep concatenating.

The first proposal seems to be the most logical one. All though it should be limited so it does not cause the node to go oom. And limit it to the V_TEXT type seems logical

I wish i had more time so i could help with it, but then i would pick up the MQTT gateway first (for example for battery level reporting) But we are in the middle of about 20 projects... Honored to be be invited, but time does not permit it.

Or a maybe bit hacky, but i think do-able is instead of putting these start-end bits in the header (to keep it small), sneaky inject them in the V_TEXT. It makes the content payload smaller, but it is multi message which then in the end makes the payload "bigger". All though it would then be possible that the last message only contains a termination byte.

I have been personally been thinking of sending multi text messages with a start and end character to be able to send longer IR codes around.

Will the V_TEXT be able to concatenate text over multiple messages together?

With PiDome you are able to add options to device skeletons you create (so you can re-use devices). When you add a device to the server you can set these options.

Example: You have 5 temperature nodes, you create a skeleton once with your temperature node setup, you add the option poll time with a drop down choosing between 1, 5, 10 minutes (you can also use input fields off course).

When you add these devices to the server you then can set the polling time per device. By using the mysensors functionality to do a data request you will be able to get the option's value (See "Requesting data" on the API page: http://www.mysensors.org/download/sensor_api_15).

But. The above does not work yet for PiDome as this is not implemented in the mysensors plugin. Too be honest i did not even have thought about it. I have created a feature request for the mysensors plugin to have this implemented at: https://bitbucket.org/pidome/pidome-mysensors/issues/4/be-able-to-create-options-for-devices-in So if you are going to use PiDome or not, this will be implemented (so other users will also be able to use it when it becomes available).

I can not yet give an estimate on when this is implemented as the Custom devices editor is on the optimization list, and currently i'm extremely busy with the raspberry pi client to have it compatible on multiple display resolutions (starting from 240*320). You have the possibility to vote for the option so it can go up on the prio list (It is the three of PiDome deciding which option is next to pick up).

Regarding of booting all the sensors at the same time. The server does not care. It is capable of handling bulk messages from the gateway. So you need @hek to answer this one.

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!

Send via chat

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.

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)

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.

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]

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!

Try to use the version from http://builder.pidome.org/view/Snapshot builds/ Make sure you clear your browser cache.

Sorry for the late response!

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" ?

This thing would be cool to have. In my setup i would really like to test this as a transceiver for my project.

The reason that the log is being filled is because despite not having the gateway ready message data can become available. I have been thinking of adding an extra switch in the software that if gateway ready is not received, but other data arrives to toggle the internal state and have the gateway marked ready. And when first data arrives ask for the version number.

I do not have enough knowledge about the differences between the FTDI FT232RL (nano) and ATmega32U4 (pro micro) when they are ready to accept data to be send to/from the gateway. If the usb chip is not ready to accept and gateway ready is send, data is lost. But this is an assumption (Arduino's only have receive and not send buffers as far as i know), maybe some hardware guru can shine a light on it.

@den2k
My test device was an Arduino Nano and have not found any issues with it. I receive the gateway ready message, and after this received i send a command to ask for the version number and this is also received. As you said you have used Pro Micro's did it show gateway ready in your Arduino terminal?

With this setup also the device discovery is tested (all though this is the exact same shared code as used for for example RFXCom devices). The device discovery works when the gateway ready message is received as then, data interaction is enabled.

No it's not (as far as i'm aware of), The gateway is like it says only a gateway (in this case only data). This means the you should do some work on the controller to be able to send this data.

The server is able to do debug logging. Could you please turn this logging on by going to: "system" > "server" > "debug logging" and switch the toggle button.

After this re-connect the serial device, turn no discovery and let the log list be filled as your screenshot shows. After a couple of minutes turn on debug logging and send me the following file "logs/system/appLog.txt" to support@pidome.org (as it may contain sensitive information so you do not want to post it online) and include a link to this thread so i know it is yours.

Cheers!

Have you turned on device discovery? Currently by default everything that can do device discovery should be enabled to do so.
It is one of the security measurements taken in the server so discovery is not enabled without user knowledge.

If it is turned on, detach and attach your pro mini (give it a second of two minimal between this) and post a part of the log where you can see the driver ask the the gateway for the version number.

As @hek says, PiDome recognises the serial gateway, it's version and displays the gateway ready message. Check your node's wiring and powering

[quote]Thank you for the kind words. I sometimes wonder if I'm sane at late nights[/quote]
No

But nonetheless, happy birthday to the mysensors.org community, and especially @hek and all the contributors with this, still, unique project!

Try to put a delay of 2 seconds in the setup part of the sketch before anything is initialized. I have encountered a "spakerFun" ebay clone board someone used (which could be identified as a leonardo pro micro from the usb descriptors). It was with a complete different project but there sketch he used just printed out the first serial output too early.

@den2k

As you say that one of the micro's is being displayed as a leonardo is because the server has a vendor and product id mapping (the usb vid/pid).
I have checked my database with vid/pid combinations and the leonardo has id 0x8036. When i check the Arduino application boards.txt file it also says that 0x8036 belongs to an Arduino leonardo. This is in this file:

leonardo.build.mcu=atmega32u4
leonardo.build.f_cpu=16000000L
leonardo.build.vid=0x2341
leonardo.build.pid=0x8036
leonardo.build.usb_product="Arduino Leonardo"
leonardo.build.board=AVR_LEONARDO
leonardo.build.core=arduino
leonardo.build.variant=leonardo
leonardo.build.extra_flags={build.usb_flags}

As you can see, this usb pid belongs to the leonardo. Are you sure you are not using a clone an/or have you selected the correct board in the Arduino IDE while uploading your sketch? If you bought originals, check the last one.

@diggs I expect the first usable snapshot builds at the end of this week. They are located at: http://builder.pidome.org/view/Snapshot builds/job/PiDome clients collection/

These clients are build to provide ease of use. Data aggregation and details will stay on the server.

@hek thanks!

@den2k PiDome really needs the gateway ready message. It then knows when the arduino is ready to handle data (as different arduino's have different serial available times (for example with the pro mini it is advised to wait a second before sending anything)).

So when you see the gateway ready message appearing in your serial monitor you are ready to go on the pi.

Do you information from nodes appearing when you leave the gateway connected?

Maybe @hek can enlighten this a bit if the gateway still sends out a gateway ready message. Which version of mysensors are you using and have you turned on/off debug message logging?

Try to make sure that you get information in the serial monitor, when it does plug it info the pi.

@diggs To use one of my clients you have to wait until November. Unless you are fine with development snapshot builds

I will not say it is the simplest way to achieve it, but currently i'm busy with updating clients to provide personalized dashboards with clients having a mobile and fixed profile. You will be able to "design" a dashboard with resizable widgets (graphs, time, media, weather, etc..)

It is being worked on by a couple of people and will replace all current clients which are now available for PiDome. But, you have to wait a bit for it. The official release is targeted for around half November.

Some screenshots:
A part of the dashboard editor with a mobile next to it for comparison: https://pbs.twimg.com/media/CLHoDJhWIAAStjp.png:large
A screenshot for showing similarities between larger interfaces: https://pbs.twimg.com/media/CLEyhQdWsAEeIOQ.png:large

For larger screens (wall mountable/tablets):
https://pbs.twimg.com/media/CMIJplgWgAAulYf.png:large
https://pbs.twimg.com/media/CMD6iCXWEAAUbVX.png:large

For smaller screens (phone targeted):
https://pbs.twimg.com/media/CMIJppKWIAAauQR.jpg:large
https://pbs.twimg.com/media/CMD6h-gWwAQs_44.jpg:large

The current larger display targeted clients for example contain customizable 3d floor maps which will also be put on devices supporting these and where not use 2d maps. There will also be support for customized dashboards for wall mountable clients using face recognition (showing the dashboard of the user standing for the wall mounted client) and a lot of other usable and maybe idiotic features. The main target is simplicity and usability on the clients where the server can be challenging.

But as said, you will have to wait until at least half way November. All clients are based on Java(FX) with a single code base so the clients will look exactly the same on every device type. We are already testing windows,mac,ios,android and raspberry pi.

@den2k

I am not seeing a gateway ready nor a mysensors version number in the last known messages. When you attach the gateway to your pc and open the Arduino monitor (setting the baud rate to 115200) could you post what you see?

I'm currently not able to test the 1.5 version of mysensors so i'm not sure if the gateway ready message is still being printed by the gateway.

Yes the popup should have been fixed. The default dashboard does a request to check if there is a weather plugin active and if there is one show the weather info (Unless you have modified the dashboard then let me know which change you made). I made an error in checking a correct field (as in time of creating i had a weather plugin active and forgot to test without having one active). If it is still there let me know as i then have to check my local development branch. (Make sure to clear your browser cache).

@den2k
Could you elaborate more on "I have similar issues that I see others have" ?

All your configurations look correct. It does not seem to correctly read the the gateway version number. This could possibly cause the problem the node id is not send correctly.

Could you remove the Arduino pro micro from the usb port, wait a couple of seconds, re-connect it, and copy/paste the "Last known messages" list after refreshing the driver page?

[EDIT]
P.S. The description for the address is shown when you would manually add this device skeleton as a device to the server. Changing it to something like a reminder of what to enter could be handy (unless this is just used as a kind of note field).

In the future it is possible to share your created devices with others, if you would publish this device to this they will see what you have entered here.
[/EDIT]

@joshmosh

When a node presents it's sensors it sends out child id's. So the controller knows which child id's exist. When values are send to the controller this is in combination with the sensor child id. So the controller knows which value belongs to which child id's exist.

If you then look at it pure from controller perspective it just sees multiple sensors. You can even put all your values within the same child id as long as the V_* types are unique used with that child id (do not use two V_TEMP values with the same child id).

@hek, @epierre

I think i was too fast with committing my updates which creates new downloads automatically (sorry if it was too quick), so I had to do a post just in case of some "eager to update" user i have.

@Daniel-Oliveira

Version 1.5 is ready to be downloaded from both regular location and the snapshot builder. Very nice to have it documented, this can help others here!

Let me know,
Cheers!

Hi All,

All new downloads from the regular download and the builder download will now offer mysensors 1.5 support. All though 1.5 is backwards compatible with 1.4 I have noticed some changes in the serial protocol between them which can influence usages:

The serial protocol for V_TYPES provides id's to PiDome via the serial gateway. Some V_TYPES share the same id. This has some consequences:
When you use V_LIGHT please update this to V_STATUS. They share the same V_** type id. The reason:

When i receive id "2" I need to check if you are using or V_LIGHT or V_STATUS and update the correct one. This means also that you can not use them both within the same sensor id. If you are using these both, but with different sensors you will be safe.

The above also applies to V_DIMMER and V_PERCENTAGE where V_PERCENTAGE will get precedence above V_DIMMER.

When you have upgraded the server, or starting with a fresh install, the log will show when a non preferred variable is used and tells to update.

Because you create device skeletons and have for example 10 of the same devices added to the server, only updating the skeleton will suffice as all devices will be updated.

The follwing V_** types are affected (1.4 namings):
V_LIGHT -> V_STATUS,
V_DIMMER -> V_PERCENTAGE,
V_HEATER -> V_HVAC_FLOW_STATE (name of the var has been changed for id 21),
V_HEATER_SW -> V_HVAC_SPEED (name of the var has been changed for id 22)

Cheers and happy updating!

Hi Daniel,

Regarding using a 7 inch screen on the central console. I'm busy with user created dashboard interfaces of which you can use. These can be shown in a browser on a tablet: https://twitter.com/Pi_Dome/status/627081006454063104/photo/1. The application i'm working on which when done will be running on Android tablets and phones (or an rpi 2) will look exactly the same and can be used as or a personal dashboard or as a client on a fixed location (more info here: http://forum.pidome.org/viewtopic.php?pid=1223#p1223)

To answer your points:
1 - This is possible using relays so a 5/3.3 volt powered arduino can switch higher powered lights (110/220 volt) and while you switch the light send a status update to pidome. I do not have a schematic available but incorporating an arduino pro/mini and the hardware to safely switch high powered items can be quite a challenge (I have seen some posts about this on this forum, but could not find them this quickly).
2 - Send a request to pidome asking the current status known. This will be send back. ( use the message type "req").
3- A: A pir sensor could be configured to send a tripped (or alike) value to pidome. On pidome you then would create an automation rule which reacts on the pir's value (tripped = true) and send a command to the selected lights to turn these on. You then can complement the rule with if the pir value = false for a certain amount of time send a command to turn it off.
3- B: If you have multiple lights as presence lights you can create a macro which turns on all these lights and a macro to turn them off and use these macro's in the automation rule.

I am currently busy migrating the mysensors support to 1.5. I would wait a bit until this is available to get a good start.

Cheers!

Congratulations to you and all contributors! I will try to update the plugin asap.

@gol

Ahh clear. I know the dependencies mentioned. Will later take a look at the software, did not had enough time to download the package to take a look into it

Very nice! Gives a nice resolution in used water. I'm wondering in defining the leakage, are you measuring the time it takes to get from region to region?

What software is used for the recognition? I'm currently busy with face recognition using opencv.

Hi @hugo_pn ,

I have posted a reply on the PiDome forum. If it is a case of mapping the sensor id (CHILD_ID from the sketches) this will possibly solve it for you: http://forum.pidome.org/viewtopic.php?id=188

Cheers!

The first one is the presentation name of the sketch on the remote node

With the second one the 0 is just an arbitrary character as I_CONFIG is just a request to the controller to send back imperial or metric

The last one are the version numbers of the library on the remote node.

Take a look at: http://www.mysensors.org/download/serial_api_14 it all is explained there

To clarify, if the node id is not defined, the remote sensor node does have an id! All though it is not a fixed one, it is id 255. This is also the reason why a id response is send to 255.

This means also that if sensors are added to the network without a fixed pre-defined id you can only add one sensor node at a time.

[EDIT]Like TimO says, the id will eventually be the id which is send back.

What you can do is send a reboot command to this new id and if both the new id assignment message and the reboot message are received the sensor will come up again and with the new id.

If the remote node does not come up again, restart the node manually to see if node id 255 does or does not re-appear. If it re-appears the message has failed. If the new node id comes up the id assignment message has been received and applied.

Also as far as i have seen a node id assignment always gives a failed response in the gateway meaning it is not a guaranteed message.

Someone correct me if i'm wrong

[/EDIT]

@blacey said:

@John Here is another option - there seems to be a lot of prior art out there that we can leverage. https://github.com/r45635/HVAC-IR-Control

Looks like they merged the library i'm using but with hvac additions. Original one i used is here: https://bitbucket.org/pidome/pidome-hardware/src/ce1d656c909b/Arduino/Uno/PiDome IR Tranceiver/?at=default My code is merely a "proxy"(wired) as it is meant to send and receive. This because codes are stored on the server. Maybe it helps. I haven't followed the whole thread, but it would be very nice if the blaster could be used to proxy. But i know raw ir signals can be too long for the mysensors payload.

@tbowmo said:

Ideally we need something to detect the carrier frequency as well.. But don't know if that is possible to obtain easily with an arduino setup

I have tried a lot of things, i ended up with recording the signals and replay them at different frequencies (36,37,38,39 and 40) and rotated the scheme. When someone got a working frequency the signal is stored with the frequency. I ended up with IRremote from http://github.com/shirriff/Arduino-IRremote as it became quite tedious. Maybe it helps.

Cheers,
John.

[edit]Sorry, now seeing that the mentioned lib has already passed by[/edit]

Currently not, zigbee is on our list, when we start to implement it it will be done per protocol, there is no estimate or decision made when to implement zll to control lighting. I'm also not sure yet if the ZLL will work on all/recent zigbee dongles because as far as i have understand it is a network not included in default zigbee mesh networks.

The last couple of months (at least 6 to 8 of them) have been quite busy for me, familiy mathers, got me a brand new daughter (https://pidome.wordpress.com/2015/05/23/baby-girl-born-our-road-to-expansion/), conferences to attend, and a lot of other exciting stuff.

This caused me to have not only some stalling in supporting MySensors on the forum here, but also in the MySensors plugin development. But i have managed to catch up. So here some important updates regarding PiDome and MySensors support:

Some weeks ago I wanted to upgrade jqwidgets (javascript framework), did not work out as expected (for the third time) so this is being removed from the server. With this removal we decided to open up everything that already has been build in in the server but not yet exposed. Every page where jqwdgets are removed are completely restyled and will also include all possibilities which should be there but could not be introduced yet because of the update pain with jqwidgets.

The most important update, next to the mysensors update of course, is that the web interface menu ha been moved from the left to the top causing a lot of space to be utilized for example for the also newly introduced customizable dashboard: https://www.youtube.com/watch?v=9_uOTYi01Is

Moving away from jqwidgets has opened up possibilities and some implications on the web interface causing some small inconsistencies, but these will be resolved soon.

The most important update of course is the MySensors support. I have bumped the support version to 1.4.1 which enables some extra options like for example the ability to show the sensor name which you are able to include within the presentation.
This MySensors update co-exists with an update in the used device discovery page. The discovery method to include MySensors devices have not changed, but are made a bit easier. The last two weeks i have been working on remodeling the auto discovery feature which for MySensors has resolved into the following:

The new discovery page

It shows the new discovery page as well the new menu structure. This page can be found under "Management" > "Device discovery". It will show you a list of drivers which support discovery of new devices. They are now marked red because discovery is disabled. Clicking on a driver will show you a couple of discovery options:

The MySensors driver supports the discovery options as shown above. You can run discovery for a single device, which means when the first device is found. It stops the discovery. Use this only when your nodes are manually assigned an address in code. Why will be apparent when you keep on reading. Discovery can also be enabled for 1, 5, 10 or 30 minutes (and then turns off automatically). and indefinitely. There is also an option Scan, but because the driver does not supports it, it is not shown.
The MySensors gateway supports inclusion mode, this is also supported within the MySensors driver. When you turn on inclusion mode on the gateway the discovery mode of the driver is turned on and will be running indefinitely until it is turned off again.

When discovery is turned on, the driver is marked green, behind the driver name will appear a "0" in blue of "0" found devices. When devices are found the number will change and an orange field will appear. The reason it is orange is because this device needs some actions. In this case the node is requesting an address. Just click on the field

This device needs an address. The driver tries to find a free address and will suggest this to you. One of the biggest changes in this routine is that the display now really shows some extra information. I would suggest you read it :).

IMPORTANT!
When you press "Set address" the server will send the new address to the node. A change in the MySensors support is that the server will send a reboot request to the node after it has send the new address. This results in the node to disappear from the found devices window where it will reappear with the new address if the remote node has received it that is. If the remote node did not received the new address, it will reappear with the address 255 again. Try to assign the address again. If the device does not re-appear, restart the node manually.

But, How do you know if a new address is assigned?

Well, when you press the orange field again, you will now be presented with the "add device" popup. You can now select the custm device you created in the "Custom device" editor (found under "Management" > "Devices" > "Custom device editor"). Set a name for this device, the location and category you would like to assign it.

Another addition to this is that the device gathered information now also shows the description you have given to your sensor.

This update comes with a couple of another updates like a notification list (message icon on the top right), page info button (the circle with the i ), a massive update of the packages page and some other stuff.

This update is available immediately as well as on the build server and as a regular download. Any questions you have can be posted on the PiDome forum, and i will try to be here as much as possible.

@C.r.a.z.y.
Unfortunately no, also it is still in alpha with builds made sometimes multiple times a day. PiDome is update safe, so stopping, overwriting, starting will handle all update tasks internally.

When stables are hitting the net we will be creating images. Until then: https://pidome.wordpress.com/server/server-installation/

@C.r.a.z.y. All input is welcome! There is an user who is running 51 devices quite stable as far as i know.

P.S.
When the rpc api is released it is possible to build an UI interface yourself ;).

@AWI Thanks! favorited the post. Will look at it when i have got the stuff to also build it.

@AWI I would be using it in the kitchen and hallway (for automatic lighting on movement etc..) so no irritating blinking when in the living room. only need to think about correct positioning as we have pets who like to rumble at night. Which motion detection solution is used? I'm using kaku now which are terrible in battery usage.

@AWI I have seen those things lying around for a couple of bucks at the action. I was only thinking about putting a pi cam in it... Do they still have them laying around?

Looks cool having the motion detector as the lens, looks futuristic. Try to put a blinking led in it, which just blinks every minute, or 45 seconds. P.S. are you doing continuously motion detection? doesn't it drain the batteries to much?

@bpair My apologies for misunderstanding, last couple of months i heard that exact same sentence but with a different meaning you gave it. Limiting possible, all though it has been running with 50+ devices and tests with multiple pi's connected are going well. Especially on the quad core pi2.

That would certainly be a nice thing! All though i think the roadmaps and primary goals are quite different where the base is the same, connect things.

It is very difficult to choose a right controller for education as there are an enormous amount of resources. An example would be the Bendoobox (from a dutch company, (i do not know if there is any mysensors support for it)) which is aiming at education. I think aimed at 12, 13, 14 year olds (average). It would be nice if there are more like these solution and hopefully for your goals.

@bpair said:

Looks great but the website says the main focus is raspberry pi. That sure seems like a mistake especially if you are using java. However as a java developer I know you do not want to spend time making sure the code runs on multiple platforms (ignore the hype about write once, deploy anywhere). Also the project only has an Alpha release!

First, thanks! Secondly, Java being slow is kind of an history. Yes the startup of the virtual machine is questionable. But the PiDome server boots below a minute on a raspberry pi B, but within 15 seconds on a Raspberry Pi 2 (this include all subsystems like database, and all SSL and non SSL services, rules, triggers, devices, plugins, etc.). The rule system makes decisions below 3 ms on a Pi B and below a millisecond on a Pi 2 per item used. Remote procedure calls are handled within 75ms average (some 100 and some 20). It ain't slow.

Yes, there are only alpha releases as the project is quite young, and i add a lot to it and development is quite fast (also it seems slow as there is just one software developer). First beta is expected June the 1st. Releases are updated daily and often multiple times a day. First add all the features, then fine tune them.

And yes, it is developed for the Raspberry Pi which also means all the binaries (which are recompiled for the pi with optimizations) needed to work with low level access on the PI are included in the package (there are also preparations made to run it on windows, mac and other linux distributions). Write once run everywhere does apply to PiDome as long as the non java (c/c++) binaries are not used, which currently is not the case. Also the base system memory footprint is just between 9.8 and 16MB. P.S. OpenHab is also Java.

I do agree, PiDome within the current state with so many updates is not feasible to be used within an environment you are looking for, even with the visual editor for mysensors devices and auto discovery. But are in discussion with an interested party to deliver such a web interface which should be able to provide easier use for for example education. Everything is done using JSON-RPC so this is possible. But don't expect this in a couple of months.

Good look with finding a solution for this, it will be a difficult one as 99% of the controllers are or not mature yet, or can be challenging. But most of them are capable.

Cheers!

Congratulations to the winners! All the projects are really evolving and getting better and better!

Also had the pleasure to play with one of these, very cool to play with, their software is bogus by the way,
A guy i know does programming with the api which is much more lightweight: https://www.youtube.com/watch?v=TS5RvqDsEoU

For me there is no need to come up with excuses, my wife is added to our team today and even knew it before me....

Gonna get me one of these. the controller already is prepared for multi core ( some components and other platform support preparations) so i wonder how it is going to perform.

@arendst
Together with an user this is implemented in the current PiDome version available on the build server. He has posted a little tutorial on how to do this. So if you are a PiDome user: http://forum.pidome.org/viewtopic.php?id=58

It is only available in the serial version for testing purposes.

If all goes well, it will be extended to the MQTT version.

[EDIT]It sends hex values which can be extracted as posted above[/EDIT]

@Derk-W.
As this is a non mysensors like device i will help you further on the pidome forum. I have seen the post but was gone all day, wasn't in the position to help earlier.

@Derk-W.

The smart meter, is it a mysensors based device?

@axillent

The latter would then be the obvious choice, wasn't thinking of that... (discard my last question)

@axillent
All clear!

I see a lot of opportunities in having a controller post sensor data to the could@node, unless you want to restrict it only to mysensors (which those segments do not imply by the way).

Cheers.

@axillent Small details can often answer big questions

Does this also mean that controllers would be able to interact with the cloud@node to be able to pass data eligible for remote storage to this instance?

How do you want to listen/sniff packets, broadcast, unicast, multicast? Or is the idea to have dedicated tcp connections to the gates?

@axillent I do get the point, but I'm having some difficulties with the drawing

The controller seems now also acting as a gateway between the home access router and the internet, introducing an extra router like device and immediate access from outside the home/business network.

I would say swap the home router and smart home texts and draw the arrow from the mobile phone to the newly located smart home text.

If the cloud@node is able to access the internet it should have a bidirectional arrow to the home router. It now seems it is able to access the internet just like the mobile without the need of a local access point. To make it more clear of the cloud@node's functionality to be able to access the internet keep the current arrow, and give the internet access arrow a different color, example green. Point the green arrow to the home router and from home router to internet icon.

@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.

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,

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.

@Zen
anycast is almost like broadcast, but with some restrictions. The most important one is broadcast (old convention method) does not care who where anycast does. More info here (too much to post): http://en.wikipedia.org/wiki/Anycast

@Zen
Oh.. Dealbreaker, A bigger reason to do anycast (if going for the *cast route), It ain't possible to squeeze a broadcast calculator in it if the multicast code would be removed?

@Zen
Use the mask to determine the broadcast ip.

Instead of multicast use anycast, this way you do not have to keep track of interested parties.

UPNP is also a possibility, it does not automatically implies router configuration options. Only implementing presence would suffice. All though space on the chips should then be looked at.

[JUSTATHOUGHT]
UPNP could also cover a bigger range of possible options where not only specific mysensor controllers can jump in to, but also other applications. UPNP enabled devices could see a MySensors gateway (it is even possible you will see it in your windows network discovery). I'm not saying to implement an UPNP subset, but broaden the gateway visibility.

I for example are going to implement UPNP for media discovery, or even other possible devices support so adding components/devices can be easier, having MySensors doing UPNP would let it appear on the list.
[/JUSTATHOUGHT]

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.

@Zen

I personally use the serial gateway, but will add ethernet support in pidome soon. This would be a nice feature to have if it was in the default mysensors lib, unfortunately i personally do not have the time to dive into the mysensors libs

@Zen
Ok clear, it would be nice if it could be added to the default libraries, maybe via a pull request via github (if mysensors is on github).

@Zen
This is in the default library? (will soon start with ethernet support).

@nneeoo said:

but in the setup() it will try to find a controller using the discovery

You want the gateway to connect to the controller? It would be better, like you said to let the gateway to broadcast a packet. When the controller receives this it can connect to the gateway. It then does not matter if the controller has a fixed ip or not because a broadcast is on network level.

It would be a good idea, it depends on if udp broadcasts are possible on the selected shield.

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).

@cayco

As the documentation states:

define TCPDUMP and connect serial interface if you have problems, please write on
http://forum.mysensors.org/ and explain your problem, include serial output. Don't forget to
turn on DEBUG in libraries\MySensors\MyConfig.h also.

Have you tried this part (define tcpdump and uncomment debug)?

[EDIT] yes you did, sorry for not correct reading[/EDIT]

As far as i also know there is no register needed because it broadcasts to any connected client. But trying to do so on "MyMQTT/#" (which is the prefix, without trailing /) would do no harm.

@tekka
Very nice approach, this could also work on other boxes where serial interfaces are not exclusively opened.

@tekka
This is very, very cool! It connects to Ethernet or does it also do serial?

@ericvdb

(Vera guess)

When given a fixed id enable inclusion mode so the device is found when you want to add it. If you are done you have to clear the eeprom and remove the fixed id from the code, and remove the device from the controller.

After the above done, enable inclusion mode again and let the auto id assignment do it's work.

@dafoink
When an peripheral is added there is an option to start, and to save and start. The save and start saves the usb port it is connected to. The start starts the peripheral, but forgets it as soon it is disconnected.

The save and start does do a check that if a specific peripheral has been saved at usb1, removed and attached again, it still is the same device.

The main reason this is implemented is that a lot are using for example FTDI. or Arduino's and attach multiple of them at the same time. By saving the mapping it kinda tries to keep the attached devices apart from eachother. It is not completely fool proof.

If the mapping is usb2, and after reboot the mapping becomes usb1, it has to be re-added. So it depends on mapping availability.
I know it is not wise to map the savings to the specific port names and it's better to be mapped to the usb bus locations and also keep the device's serial numbers (not only vid and pid) where possible. It is on the list ;).

@hek
Understood, i meant how they want to receive the data. @BulldogLowell would like to receive a long instead of an hex string (if i understood it correctly).

That's the part i'm interested in.

Then to make sure there is as less data as possible over the air then this would mean to send data as: "000000" to "ffffff" (so no "#" char)

This also has my personal preference, but want to know how the community would like it to handle it on the node side.

@BulldogLowell
Yup, i'm spoiled.....

I will take this option in consideration. It does depends on what users would prefer the most.

@BulldogLowell
Was thinking 32bit, sorry....