piBeacon: 3- presence monitoring download

posted 1-17-17

fixed:
error message: "piBeacon in Line '3686' has error=''key address not found in dict''

posted v 1.17-19

fixed:
- internal logic
- position calculation of iBeacons and BLEconnect devices
- BLE connect only worked for ~ 1 minute in parallel mode, then it switched back to serial mode.

changed
BLEconnect on the rPi now does the WHOLE command in one shell instead of 3 separate steps. This seems to be much more stable and delivers much better results

Code: Select all

 "sudo hcitool cc " + mac + "; hcitool rssi " + mac + "; hcitool tpl " + mac

instead of 3 sequential hcitool calls and only executing 2. step if 1. step shows no error message.

It seems that even if the first step shows an error message like "Input/output error" it still connected and got the signal strength and transmitted power. Hence error messages or error exit codes have no real correlation to a basic connect. It might not have been fully successfully connected but the iPhone did answer and some packages were send. That is enough to establish UP/down detection and delivers signal strength and transmit power (RSSI and txPower)

With this change and running in parallel mode the BLEconnect mode seems to be stable and accurate.

Karl

posted v-1-17-20

fixed:
- temp sensor oneWire setting was screwed up since 1.17.16
- fixed command "sudo python installLibs.py &": works now to launch manual system upgrade / update, might take 1-2 hours depending on how old your op-sys is
- minor language fixes.

if everything works with .19 for you, no need to upgrade. Mostly maintenance things

Karl

posted v-1-17-22

fixed:
1. when error in edit device a wrong property was added, that caused downstream problems

2. added:
- timeout parameter for BLE connect . This will allow FAST response time to "hcitool cc mac#" queries. fastest timeout is 1 second. You have to set it in device edit for each BLEconnect device
- if indigo web userid is empty it will not use userid password -- not tested!!

I have tested this remotely ONLY -- no guarantee. Be prepared to go back to v1.17.19 if it breaks.

Karl

posted v 1.17.23

added fine-tuned parameters for timeout, 0.1 secs steps (only changed devices.xml file)

Code: Select all

           <Field id="iPhoneRefreshDownSecs" type="menu"     defaultValue="10">
                <Label>try to reach iPhone when DOWN again after:</Label>
                <List>
                    <Option value="0"   > try continuously </Option>
                    <Option value="0.1" > 0.1 secs</Option>
                    <Option value="0.2" > 0.2 secs</Option>
                    <Option value="0.3" > 0.3 secs</Option>
                    <Option value="0.4" > 0.4 secs</Option>
                    <Option value="0.5" > 0.5 secs</Option>
                    <Option value="0.7" > 0.7 secs</Option>
                    <Option value="0.9" > 0.9 secs</Option>
                    <Option value="1"   > 1.0 secs</Option>
                    <Option value="1.5" > 1.5 secs</Option>
                    <Option value="2"   > 2 secs</Option>
                    <Option value="5"   > 5 secs</Option>
                    <Option value="10"  > 10 secs</Option>
                    <Option value="30"  > 30 secs</Option>
                    <Option value="60"  > 60 secs</Option>
                    <Option value="90"  > 90 secs  (default)</Option>
                    <Option value="120" > 2 Minutes  </Option>
                    <Option value="180" > 3 Minutes  </Option>
                    <Option value="300" > 5 Minutes  </Option>
                </List>
            </Field>
            <Field id="iPhoneRefreshUpSecs" type="menu"     defaultValue="90">
                <Label>try to reach iPhone when UP again after :</Label>
                <List>
                    <Option value="3"  >3 secs</Option>
                    <Option value="5"  >5 secs</Option>
                    <Option value="10" >10 secs</Option>
                    <Option value="20" >20 secs</Option>
                    <Option value="30" >30 secs</Option>
                    <Option value="45" >45 secs</Option>
                    <Option value="60" >60 secs</Option>
                    <Option value="70" >70 secs</Option>
                    <Option value="80" >80 secs</Option>
                    <Option value="90" >90 secs</Option>
                    <Option value="100" >100 secs</Option>
                    <Option value="120" >2 minutes</Option>
                    <Option value="150" >2.5 minutes</Option>
                    <Option value="180" >3 minutes</Option>
                    <Option value="240" >4 minutes</Option>
                    <Option value="360" >5 minutes</Option>
                    <Option value="720" >8 minutes</Option>
                    <Option value="600" >10 minutes</Option>
                    <Option value="1200" >20 minutes</Option>
                </List>
            </Field>
            <Field id="BLEtimeout" type="menu"     defaultValue="10">
                <Label>time out BLE query after:</Label>
                <List>
                    <Option value="0.5"   > 0.5 secs</Option>
                    <Option value="0.6"   > 0.6 secs</Option>
                    <Option value="0.7"   > 0.7 secs</Option>
                    <Option value="0.8"   > 0.8 secs</Option>
                    <Option value="0.9"   > 0.9 secs</Option>
                    <Option value="1"     > 1.0 secs</Option>
                    <Option value="1.1"   > 1.1 secs</Option>
                    <Option value="1.3"   > 1.3 secs</Option>
                    <Option value="1.5"   > 1.5 secs</Option>
                    <Option value="2"     > 2 secs</Option>
                    <Option value="2.5"   > 2.5 secs</Option>
                    <Option value="3"     > 3 secs</Option>
                    <Option value="4"     > 4 secs</Option>
                    <Option value="5"     > 5 secs</Option>
                    <Option value="10"    > 10 secs = off  </Option>
                </List>
            </Field>
 

Karl

posted v 1.17.25

fixed:
1. switching between BLE-connect sequential/parallel works now

added:
1. option to do an rPi system upgrade from the menu (this might take some hours on each rPi), select in menu in send updates ..
2. option to NOT delete new beacons if they are not renamed within 1 hour. This is set in config
3. added a UUID state to the iBeacons. As you have the option to replace the UUID with the beacon family name in the Notes field the UUID was not visible anywhere. This new device/state will now show you the full UUID-minor-major
4. logfile management is now integrated into rPi op-sys. Every 30 minutes check: if <55% of disk-space is left: a log file rotate is force; and daily it does the normal rotate. max log file size is 1MByte per log file. 4 versions are kept ( .log; .log.1; .log.2;. log.3). All files in /var/log/...


Karl

v 1.17.27 posted

added:
- option to restart / not restart the BLE stack if no messages have been received within 5.. minutes (set in Config)
- some formatting text, help text
- tuned the logging rotate parameters on the rPi: force login rotate
if % disk-space left< 80% AND less than 1GByte left on SSD .
It is important to leave some room on the SSD otherwise logging etc might fail. Also if too little space is left the SSD might wear out.
- when a BLEconnect device(iPhone) is enabled/ disabled now the rPi gets properly updated in its config files to switch BLEconnect on/off appropriately



Karl

V 1.17.28 posted:

fixed:
- rare condition: if a rPi was not connected and a reboot of another rPi was requested, it did not do the reboot as it was stuck trying to connect to the missing rPi.
- sensors.py: a syntax problem on the rPi, affected "alive" packages if no message send for > x minutes

added:
- option to do a retry if BLE-device (iPhone) was away and comes back online to do 2 connect tries (0.5 seconds apart). This should remove false positives in parallel mode.
this option can be selected in the rPi device edit as it is valid for all BLE devices assigned to an rPi.

Karl

v-1-18-2 posted

added:
request new data immediately from rPis for the following device types (all)
- BLE-connect
- sensors
- iBeacons
you can request this from the menu, an action or through a python script:

Code: Select all

plug = indigo.server.getPlugin("com.karlwachs.piBeacon")
plug.executeAction("newMessage" ,
   props={
   "piServerNumber" :"0" # for pi # 0, .."9" and up to "19" for sensor rPis
   ,"typeId": "BLEconnect"  # or "sensors" or" beacons"
   }
)

fixed:
some language, typos


Karl

posted V 1-19-6

fixed/improved:
- automatic push of changes to the impacted rPi did not happen for all changes in device edit, should now cover all (most) properties changed
- more consistent alive packages from the rPi, in case no sensor / beacon .. is active.
- in case a rPi is offline the message displayed always showed 1 minute offline. It now shows the right amount of time offline.


new:
- most device type now show a status symbol in the main indigo window (temp/humidity/ on-off/ beacons, rPi ... dimmers etc)
- allows to connect and many DHT-xx sensors, as you have free pins
- new structure for sensors and outputs mostly for GPIO pins ==> this a major structural improvement. You now can assign (almost) any pin to be an input or output GPIO pin. so you could have all output puts or all input or any mixture.

• there are now device types that have 1,4,10,26 pins for INPUT as well as OUTPUT
• you can have multiple one GPIO-pin devices defined. Advantage is each PIN can be its own device and can use all the options available for devices: e.g. you can show each PIN state in the status column and for OUTPUT the GPIO device is defined as an "indigo-dimmer" which means that you now can set the pins in the indigo main window (turn device on/off/ dime by etc), on the iPhone etc with std indigo tools. the dimmer functionality is simulated with PWM. That works perfectly for LEDs. You still can use the defined actions to change anyGPIO as before (through the parameters have changed)
• with this setup you can have 14 output pins and if you add the TX-RX and DHT and oneWire pins up to 18 input or output pins or a combination of x-INPUT & y-OUTPUT PINS. Any pin can be assigned to any INPUT or OUPUT state in the devices (you need to set it up in the device edit)

you need API version 1.18 for this Indigo >6.1.10 should be fine

Karl

the main window with the new state symbols

Screen Shot 2016-05-15 at 5.20.33 PM.png (226.17 KiB) Viewed 4989 times

the device input edit

Screen Shot 2016-05-15 at 5.23.11 PM.png (90.54 KiB) Viewed 4989 times

selection of the GPIO-pins, all pins w/o comments should work fine for input as well as output

Screen Shot 2016-05-15 at 5.22.11 PM.png (73.16 KiB) Viewed 4989 times

using the indigo device dimmer to set GPIO-OUTPUT pins

Screen Shot 2016-05-15 at 5.21.17 PM.png (32.62 KiB) Viewed 4989 times

posted v 1.19.7

fixed:
I screwed up "sensor edit" and "ignore new beacons" in 1.19.x, fixed now (when I "optimized" deviceStart and deviceStop )

added:
"beautification":
- state symbols for beacons now have 3 images for up/down/expired (green/grey/red)
- the notes field now has some more info info for sensors (i.e. which GPI-pin used, which i2c channel etc)

posted 1.19.8


fixed:
in edit sensor device: when switching the associated PI# it blew an error.

added:
more option for status display with sensors e.g. temp/humidity instead of just temp OR humidity , see attached screen shot.

Karl

posted v 1.19.9

fixed:
when defining inputGPIO devices the validate section of the plugin had a typo. caused an error message = could not define these devices

Karl

posted v 1.19.10

fixed:
some how I added a wrong line in the last versions that prevented new rPi devices be created properly. If you don't want to add/ change an rPi you are ok, but if you do (also replace) you MUST upgrade otherwise your setup will be screwed up and you might need to start from scratch..

Karl

and thanks to Matt for debugging

posted v 1-19-12

fixed:
a typo in a debug statement that caused an error - only if that error occurred

added:
check for indigo-server communication timeouts. It should handle that now more gracefully - instead of deleting devices it assumes do not exist.
Probably have not covered all possibilities, but the majority cases should be covered.
BUT if you have server communication issues YOU REALLY SHOULD CHECK THAT OUT.

Karl