iia

Is the AP in N-only mode? If so then try to configure it in B/G/N mode. This can be an issue for hidden (no SSID broadcast) APs as discussed here, https://github.com/esp8266/Arduino/issues/3457.

Another thing to try would be to make sure the AP is not switching to a different channel. For example some APs have the feature of switching to a different channel if it detects the currently used channel is over crowded with other APs around. Particularly applicable for 2.4GHz APs.

Cheers.

Hi @peter_tau,

I did a simple test with 1.12 image on the RED Brick. The hardware setup looked like:

                Humidity Bricklet

                        |

                        |

                        |

                        v

|RED Brick|==>|Master Brick|<---Temperature Bricklet

                        ^

                        |

                        |

                        |

              Ambient Light Bricklet

Items file:

Number TF_Temperature   "Temperature [%.1f °C]" { tinkerforge="uid=zFd" }
Number TF_Humidity      "Humidity [%.1f %%RH]"  { tinkerforge="uid=qTQ" }
Number TF_AmbientLight  "Luminance [%.0f lx]"   { tinkerforge="uid=uKN" }

Sitemap file:

sitemap test label="Test: OpenHAB 2 @ RED Brick"
{
    Frame {
        Text item=TF_Temperature
        Text item=TF_Humidity
        Text item=TF_AmbientLight
    }
}

With this setup I got the following timing:

• The setup showing up on Brickv after a reboot: 1.5 minutes
   
  
• The sitemap being available and functional since reboot: 9 - 10 minutes
  

Once the sitemap is up and running then everything goes quite smoothly without much lag and is definitely usable.

OpenHAB 2 is known to be slow, very resource hungry and not suitable for resource constrained systems. Some discussions on this topic:

1. https://github.com/openhab/openhabian/issues/171

2. https://github.com/openhab/openhab-distro/issues/10

When OpenHAB is run for the very first time it will take even longer to finish the setup. But subsequent startups are supposed to take less time than that.

Now about if you can do something to improve the situation. You can try to specify only the UIs and the setup you need in the config file:

/etc/openhab2/services/addons.cfg

For example only enable Basic UI. Reboot the system after changing this config file.

Can you provide me with your .items, .rules, .sitemaps files and also the three OpenHAB2 log files located at:

/var/log/openhab2 ?

Cheers.

Hi Nic,

After doing a scan from Brickv with the particular WiFi card can you provide us with the following data:

1. dmesg output

2. Content of /var/log/syslog

3. Content of /var/log/wicd/wicd.log

If you execute the command,

sudo iwlist scan

on RED Brick command line what output do you get ?

Dear Equinox,

Good finding. The problem is it should be,

Tinkerforge.BrickletRemoteSwitch.SWITCH_TO_ON

instead of,

BrickletRemoteSwitch.SWITCH_TO_ON

Will be fixed in the examples.

Hei Tinkerers,

We have finished working on the new Javascript bindings which will support both browser and Node.JS. Currently for testing only the Node.JS version is available.

The bindings are already in NPM registry.

First of all, you need to have a working Node.JS installation and NPM installed on your system (better if they are updated to the latest version).

Then you can install the bindings using the following command,

sudo npm -g install tinkerforge

You must make sure that the environment variable `NODE_PATH` is in your env list. This is usually pointing to `/usr/local/lib/node_modules/`.

After that you should be able to try out all the examples found in the attached archive with the following command,

node <exmaple_to_execute.js>

Don't forget to change the UID and network parameters depending on the setup you are testing on.

Have fun trying out the new bindings and it would be very much appreciated if you post your findings and feedback on this post.

Cheers,

Ishraq

NodeJS_Examples.zip

NodeJS_Examples.tar.bz2

Hei Robin,

Thanks again for a very important finding! I fixed it in the code. Please do inform us if you find more issues.

Ishraq.

Hei Robin,

Thanks for your feedback.

As borg mentioned, the bindings are already generated and resembles the previous bindings.

It will be official and we also planned to put it in CPAN.

But before that little bit more testing is needed for the implementation.

Ishraq.

Thanks Nic.

Hei people,

I am a new employee at Tinkerforge and recently I have been working on a new perl binding. Attached are the compressed files of the binding in current state.

Directory Structure:

• api
  
• bindings
  
• examples
  

api: Contains the main api files.

bindings: Contains the device class files.

examples: Contains examples to get an idea of the API usage.

This API requires that your system's perl installation has the latest Thread::Queue perl module.

One can update this via CPAN,

sudo cpan

and then on the CPAN console,

upgrade Thread::Queue

Note the two lines at the beginning of the example scripts,

use lib '../api';
use lib '../bindings';

Change these two lines accordingly to point to the api and bindings directories (if you changed/moved the files).

While using the examples don't forget to change the device and their UIDs according to your setup and the same for the host.

Try the beta API out and report findings, bugs, suggestions etc here.

tf_perl_api.zip

tf_perl_api.tar.bz2