Is there a way, through the API to set the wifi configuration and/or the lat/lng coordinates of the station?
Nope!
The API allows data to be fetched only. All configuration happens through the app/web
how would the server api communicate if the wifi isnât set?
2 Likes
My comment referred to both location and wifi.
But imagine one wants to completely interact with the device without human interaction. And there is a desire to change the access point that is located nearby. That would require changing the hub prior to the old access point going away and doing it all through the API. No reason to preclude operations that can be useful.
It just isnât worth the programming effort to add this just in case one person, once every 5 years is in need for a hypothetical case of changing an AP without human interaction. If the api call would exist you would still need to start an app or program to perform the api call. So human interaction is always needed. There is already an app to change the WiFi and the same app can be used to change Lat/Long.
Sorry, but there is a limit to usefulness.
Consider the following scenario.
I want to deploy WF in a fully integrated system. The customer will receive preconfigured components so simply needs to physically place the components and plug things in. The end user never deals with the WF app.
Now, imagine another part of the system knows the lat/lng where the system is placed. Dont you think WF wants to know the lat/lng of where there device is? The API that allows reasonable configuration would allow this integration model to be supported. Currently it does not.
Not possible with the current firmware. For the initial installation of a station youâre going to need something in the firmware to let you configure the wifi settings for the Hub at a minimum. Currently that means Internet connectivity, a WF account, and their bluetooth mobile app for at least initial setup.
How exactly would you handle that chicken-and-egg situation without some app that can talk to the Hub like the current bluetooth bootstrapping works ?
[âŚedit - I might add that Ecowitt gateway setup happens very similarly via âtheirâ appâŚ]
The API currently is read-only which makes the security side of things much simpler to deal with for WF. If they permit read-write for anything, it opens up a whole canâoâworms to consider. Not trivial.
You continue to talk very obtusely about what youâre trying to build so itâs hard to say more than âit is what it isâ. Iâd be fascinated to hear of âanyâ vendor with a network attached system that âisâ as flexible as you seem to think things should be. Maybe that would help us understand what youâre looking for architecturally.
| vinceskahan
June 7 |
- | - |
brian.koblenz:
I want to deploy WF in a fully integrated system. The customer will receive preconfigured components so simply needs to physically place the components and plug things in. The end user never deals with the WF app.
Not possible with the current firmware. For the initial installation of a station youâre going to need something in the firmware to let you configure the wifi settings for the Hub at a minimum. Currently that means Internet connectivity, a WF account, and their bluetooth mobile app for at least initial setup.
How exactly would you handle that chicken-and-egg situation without some app that can talk to the Hub like the current bluetooth bootstrapping works ?
I think I indicated that I would preconfigure the wifi with my integrated product prior to delivering to the customer. The location where the customer would deploy, however is not generally known. So I dont think there is any chicken/egg problem.
[âŚedit - I might add that Ecowitt gateway setup happens very similarly via âtheirâ appâŚ]
Now, imagine another part of the system knows the lat/lng where the system is placed. Dont you think WF wants to know the lat/lng of where there device is? The API that allows reasonable configuration would allow this integration model to be supported. Currently it does not.
The API currently is read-only which makes the security side of things much simpler to deal with for WF. If they permit read-write for anything, it opens up a whole canâoâworms to consider. Not trivial.
I did not ask to modify âanythingâ, but I think there is a set of reasonable configuration information that one could reasonably want to modify and that modification can/should be done over the internet.
I am not trying to be obtuse. We build internet connected distributed control systems with configurable inputs and outputs and actions that can be taken based on those inputs. (Think distributed internet connected PLC) (I view the Tempest as just a bunch of input sensors in my system that are nicely packaged.) While we do not expose an API to customers, there IS an underlying API that allows configurations to be read/modified over the internet in a way that is secure and protected.
You continue to talk very obtusely about what youâre trying to build so itâs hard to say more than âit is what it isâ. Iâd be fascinated to hear of âanyâ vendor with a network attached system that âisâ as flexible as you seem to think things should be. Maybe that would help us understand what youâre looking for architecturally.
We have previously integrated davis weather stations into my product. Davis provides an interface where I can change the state of various weather station parameters like time and location etc. They are not internet connected, per se, but one of my users (with appropriate rights) could move their instance of my product and change (over the internet) the lat/lng coordinates of the attached davis weather station. Similarly, I have some users that want to be alerted when there is a 20km/h wind gust and others at 40km/h. To me, this is a configuration parameter that needs to be controlled by the end user and changeable over the internet. We can certainly do that with our system so I think what I am asking does indeed have an existence proof.
I am not trying to say this is a showstopper kind of request. I am simply stating, from an integratorâs perspective, there are operations that could be automated (like setting lat/lng) given more general APIs and, as I now understand, those operations are not possible today. I am not interested in debating the âimportanceâ of this.
It sounds like you need to contact WF directly about what you want to do. There may be something you can work out with them that isnât generally available otherwise.
Not questioning perceived importance. Questioning for clarity in for what youâre actually asking for.
Davis has an interface, yes, to set station parameters by communicating with the station console directly (using my serial-connected VP2 as an example). They also support alerts.
Iâm not aware that WF supports either thing at this time.
Iâm still not understanding how you would preconfigure a customerâs wifi. I know Iâd never give you the wifi configuration info to do it, FWIW. But best of luck there. I donât have to understand it anyway.
It occurs to me (I am a little slow:)) that I cold likely use the bluetooth interface to the hub to configure these values.
I did see a reference to a bluetooth API being published but it seems that has not happened so I doubt it is coming real soon now.
Has anyone reverse engineered the bluetooth interface? I was thinking about starting that but figured I would ask here first.
Also, has anyone been able to access bluetooth services and attributes after connecting to the hub? If so can you let me know what approach you used? (I have tried hcitool, bluetoothctl, and the bleak library but in all cases I cannot get any services/characteristics/attributes.
-brian
Hi Brian,
I have two thoughts.
There may be feature requests involving using a Tempest on a moving vehicle such as motor home or sailing boat where people would like a moving location.
Also I have commented previously how the current station location being a database field of the hub is not ideal because a hub can connect to sensors many kilometers away such as my Sky sensors which are up to10km in different directions.
If each sensor had a new database field added for its location then it might also be moving.
With the current limitations from Weatherflow I wonder if you create your own server that provides a database which links a tempest to a location and it could be moveable.
Cheers Ian 
1 Like
I finally found a tool that allows me to interact with the hub via bluetooth. I still cant get/set lat/lng, but I am hoping I will eventually figure out how to do that. If someone from WF would provide some input that would be great!
In the meantime I have done some reverse engineering of the bluetooth data and I figured I would share that here.
First, the general command to issue (at least from my pi) that allows me to get hub updates from bluetooth is:
gatttool -b C0:EE:40:72:7B:16 --char-write-req -a 0x002b -n 0100 --listen
(the C0:⌠is the address of my hub. You need to scan your bluetooth to find the address of yours.)
For those not as familiar with bluetooth (like me) things are little endian, so the gattool line writes a 2byte 0x1 to handle 0x2b which is what enables notifications for handle 0x2a. (fwiw, there also seem to characteristics that support notification by writing handles 0x33 and 0x43 but I have not been able to get any data.)
When the gatttool command runs you get an ongoing stream of output which looks like:
Notification handle = 0x002a value: 18 67 a5 db 3a 06 65 10 00 eb 00
Notification handle = 0x002a value: 18 67 a5 df 3a 06 65 41 00 d7 00
Notification handle = 0x002a value: 18 67 a5 e2 3a 06 65 4f 00 c5 00
Notification handle = 0x002a value: 20 67 a5 00 02 00 00
Notification handle = 0x002a value: 1a 53 54 2d 30 30 31 30 37 38 37 39 00 c1 04 14 ac 00 0b 00
Notification handle = 0x002a value: 18 67 a5 e5 3a 06 65 40 00 bb 00
Notification handle = 0x002a value: 52 67 a5 e3 3a 06 65 57 a9 00 00 23 01 94 9f 08 00 69 01
Notification handle = 0x002a value: 53 67 a5 e3 3a 06 65 57 00 ce 00 0b 00 c7 00 59 00 03
Notification handle = 0x002a value: 54 67 a5 e3 3a 06 65 6c 0b 2e 0c 00 00 00 10 71 01 00
Notification handle = 0x002a value: 18 67 a5 e8 3a 06 65 28 00 d2 00
Notification handle = 0x002a value: 18 67 a5 ea 3a 06 65 0c 00 d2 00
In general, I believe the messages starting with 18 are ârapid windâ descriptions and the most of other entries describe observations.
So, byte 0 (B0) is the descriptor, and for most entries (except 1a) I do not know what B1âŚB2 are.
Below, I describe entries (indexed by B0) in groups like [n/e desc] where the next ânâ bytes should be interpreted as desc. e is typically an exponent of 10 (ie 10**e) that the value is multiplied by to get the actual value. If e==âaâ the bytes are intrepreted as ascii. So [4/-2 speed] would take the next 4 bytes (least significant byte first) to produce a 32b integer value which is them divided by 100. to get the actual floating point value for speed. As an example 2/-1 applied to fb 01 would equal 50.7
Anyone who can validate/correct what I have deduced and/or can fill in the blanks, please do.
18 [2 unknown] [4 timestamp] [2/-2 wind speed] [2 wind direction]
1a [11/a station number] [2 unknown] [2 unknown] [1 station firmware] [2/-3 battery level] [1 unknown]
52 [2 unknown] [4 timestamp] [4/-2 illuminance] [2/-2 UV] [4/? rain related?] [2/-2 solar radiation]
53 [2 unknown] [4 timestamp] [2/-2 wind avg] [2 wind dir] [2/-2 wind lull] [2/-2 wind gust] [2 unknown] [1 wind sample time]
54 [2 unknown] [4 timestamp] [2/-2 temp] [ 2/-2 rel humidity] [3 unknown] [4/-2 station pressure]
2 Likes
why do you assume the hub needs lat/long settings or even when it does, why that is set via Bluetooth? I donât know nothing about this, but my first assumption would be that this is a setting stored on the server, set via the interface on the app.
2 Likes
I dont know. But would like to! The app is BT connected to the hub to set things up so it is plausible that it goes through BT and the hub but also plausible it goes directly to WF. However, WF says there is no API soâŚ
as mentioned I donât know, but I think it is a safe bet that the app communicates the lat/long directly to the servers and there isnât a public api call available to retrieve it.
1 Like