Done. Noch am langsam-Wachsen:
Wesentlich Änderungen in der Software zu v0.0.3-rc1 (die beiden hier in diesem Thread vorher geposteten Versionen heißen hier jetz v0.0.1 und v0.0.2):
Hier auch noch mehr zum Thema.
Wie immer: It’s a feature, not a bug!
With that in mind, all in all, it makes 100% sense not to have DNS in LTE-NB1 … and all we have to do is design our solutions around this factor.
So ein Quatsch!
Viel schlimmer als fehlendes DNS finde ich das hier.
Furthermore, in some cases like Vodafone in Ireland (the info I got from someone there), is that “the network” is only a “local network” inside Vodafone … so you’d have to send your data to a Vodafone server (via IP) … and then pull it out via MQTT / API’s from their server into your Portal …
Ist auf alle fälle der Tod für IoT und Roaming über verschiedene Anbieter sowie für Plug&Play beim Endverbraucher wie soll das gehen?
Hoffe mal bei den Deutschen Anbietern ist das nicht auch so.
Kein wunder das sich in der Richtung so wenig bewegt.
TLDR; macht euch nich so viel kopp ueber solche detaillimitationen. ;)
ich denke da habt ihr nb1 und m1 falsch verstanden… das ist fuer ‘ich baue viele davon’ … dann ist der setupaufwand fuer einmal eher vernachlaessigbar
gegenteil… mit ohne internet dazwischen ist man flexibler und braucht sich um vieles weniger kopf machen (wie z.b. dns)
die simkarten wie wir sie nutzen waren und sind nicht dafuer gedacht direkt bezogen zu werden.
das ist und wird vermutlich auf ein paar jahre ein produkt bleiben das man idr direkt mit dem device kauft.
bei einem modernen auto steckt auch ne sim drin. die hat da natuerlich der hersteller reingesteckt und nicht der kunde oder die werkstatt. man braucht ja eh noch das ‘backend’ mit dem $iot-device (da zaehle ich autos und co zu) das dem kunden dann das userinterface gibt (die cloud platform)
;)
wir muessen wir eh fuer jedes transportmedium dinge wegabstrahieren:
alles transportmedien die ihre eigenheiten haben. das alles komplett generalisieren wird nicht klappen.
da wir aber nur ‘einen klumpen json von node zu server’ bringen muessen… findet sich da sicher fuer jedes medium ein passender weg.
auf ip haben wir mqtt… das passt da super.
das bei nb1 das dns fehlt finde ich nich schlimm (openvpn -> statische ip vom server im tunnel) dafuer ist der rest ‘einfach’ weil auch ip.
alles was nicht ip ist… muss man am ende erst wieder kapseln und das ist nun leider manchmal etwas unterschiedlich
ps: ich finde bisher keine definitive aussage das dns bei nb1 garnicht geht, sondern nur das es diesen bug bei pycom oder den implementationen bei den carriers gibt. vll loest sich das auch mit zeit einfach auf.
DNS geht, was habt Ihr denn alle… ! B)
>>> import usocket
>>> usocket.dnsserver(0,'9.9.9.9')
>>> usocket.dnsserver()
('9.9.9.9', '0.0.0.0')
>>> print(usocket.getaddrinfo("weather.hiveeyes.org", 80)[0][-1])
('46.4.251.67', 80)
klappte gerade mit @wtf’s FiPy.
Manchmal klebt es:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OSError: [Errno 202] EAI_FAIL
update: der EAI error kommt u.a. dann, wenn als zweiter DNS server bogus eingetragen ist (0.0.0.0) , die Dinger werden alternierend abgefragt - daher mußte er dort abbrechen.
Der Fehler kommt auch, wenn man nicht attached und connected ist! ;)
rocknroll… d.h. der ‘bug’ ist nicht das nutzen von dns an sich (waer auch komisch, iss ja nur udp) sondern das vom ‘netz’ kein nameserver gesetzt wird %-) … also DAS ist einfach zu fixen :) (solange man nicht bei vd2 ist , die offenbar in uk dns auf alle ausser ihre server filtern)
Finde nicht das Ich /Wir das falsch verstanden haben, sondern die Anbieter solcher Karten. Die wirklich großen wie die Autoindustrie haben bereits schon ihre Lösung durch Sonderverträge und dergleichen. Der Mittelstand und die kleinen Krauter haben wie immer das Nachsehen. Ach ja und genau dafür würde NB1 gerade Anfangs ja beworben.
finde ich auch das DNS kein must have ist. Finde nur eher blöd, wenn mann da auf einem Anbieter und ein Portal dazwischen ausgebremst wird, das man zusätzlich evtl auch noch umständlich konfigurieren und sich alles andere danach verbiegen muss.
Ist auch noch sehr begrenzt in der Bandbreite, eine Nachricht darf nur 12 Byte haben und es dürfen pro Tag nur 140 Nachrichten verschickt werden. Geht daher eher nur für sehr wenige Sensoren oder Status und Fehlermeldungen. Ach ja und wider so ein Blödes unübersichtliches Portal was die Daten weiterverteilen soll. Der einzige Vorteil den Sigfox hat ist das wir mit dem FiPy eine Jahreslizenz for Free haben.
wenn der krauter keinen openvpn aufgesetzt bekommt sollte er vielleicht kein b2b produkt kaufen. das ist in dem fall eine echt niedrige huerde.
und ich seh da genau garkeinen zielgruppenfehler auf seiten von carriern wie 1nce.
das ist fuer menschen die wissen wie die technologie funktioniert die pro kunde tausende sims brauchen. rent-a-netzbetreiber. ist doch super. einfacher geht nicht.
kundensupport pro sim ist dann der job desjenigen der das produkt verteilt. und das kann hier ja ab der ersten sim jeder sein. dafuer bekommt man ja das webinterface (fuers reinschnuppern) und die api (um das dann in die eigene plattofrm zu integrieren.
deswegen kann man auch simkarten per api bestellen usw.
d.h. der unbedarfte der mitspielen will kauft nicht bei 1nce die sim sondern beim plattformbetreiber… also z.b. uns?
normalerweise bekommt man so tollen zugriff auf ein gsmnetz nur wenn man einen sehr teuren vertrag und ein paar (zig)tausend sims minimum braucht.
das hat dann monate vorlaufzeit und tunnels fuer sowas sind idr ipsec und brauchen diverse lange telcos ueber mehrere wochen zum aufsetzen.
das als ‘ich bestell was im webshop’ zu retargeten ist schon extrem positiv fuer uns.
ich bin jedenfalls bisher positiv ueberrascht. naja… more classy hosting als amazon waere schick, aber sonst faellt mir echt keine kritik ein. das ist echt selten fuer mich im kontext carrier! ;)
Na also. Irgendwie sowas dachte ich mir schon. Merci fürs ausprobieren!
Yeah!
Putting "class SQNS" into your boot.py will give you a "sq" shorthand to the REPL. Use it like
>>> sq.info()
>>> sq.firmware_info()
>>> sq.at('showphy')
>>> sq.raw('AT+CLAC')
to save many characters and typos when exploring the innards of the modem interactively.
class SQNS:
"""
Synopsis::
sq = SQNS()
sq.info()
sq.firmware_info()
sq.at('showphy')
sq.raw('AT+CLAC')
"""
def __init__(self):
from network import LTE
self.lte = LTE()
self.at('RRC:setDbgPerm full')
def at(self, command):
self.raw('AT!="{}"'.format(command))
def raw(self, command):
print('Sending command {}'.format(command))
print(self.lte.send_at_cmd(command))
def info(self):
# https://forum.pycom.io/topic/4022/unable-to-update-gpy-modem-firmware/8
self.at('AT')
self.at('ATI')
self.at('ATZ')
def firmware_info(self):
import sqnsupgrade
sqnsupgrade.info(verbose=True, debug=True)
def unbrick(self):
raise NotImplementedError('https://forum.pycom.io/topic/4022/unable-to-update-gpy-modem-firmware/21')
global sq
sq = SQNS()
There really are two commands for ending the connection:
lte.detach()
lte.dettach()
Both work the same way, but as ‘dettach’ is ‘going berzerk’, this only could result from a typo in the code - and yes, there is some hint to it (see the comment after the 2nd, the ‘dettach’):
So true. I believe this already has been discussed on the Pycom Forum somewhere. I also believe it has already been fixed in the development releases of the Pycom firmwares.
Unsure if we posted this already. Just for the sake of completeness and for all who are interested in lowlevel things like that…
… Voice-over-LTE (as mentioned on the cover) … mentioning this just in case somebody wants to transmit audio … there might be a chance, but I guess only within a Cat-M1-network, not within the NB-IoT spec.
From page 293 ff. of https://nimbelink.com/Documentation/Skywire/4G_LTE_Cat_M1/1001799_NL-SW-LTE-SVZM20-B_AT_COMMAND_MANUAL.pdf.
ATD<num>[;]Possible Response: <status>
ATD*99[*[<called_address>][*[<L2P>][*[<cid>]]]]#Possible Responses:
CONNECT
NO CARRIER
ERROR
+CME ERROR:<err>
ATD is used to set up outgoing voice call.The syntax ATD*99# causes the MT to perform whatever actions are necessary to establish a communication between the TE and the external PDN. See also 12.2 Setup PPP Connection ATD*99 on page 273.
num
String of dialing digits and optional V.250 modifiers: 0-9, *, #, +, A, B, C, D and p.
status
String. Result of the command.
| Value | Description |
|---|---|
| OK | Call successfully dial and start to ring back |
| BUSY | MT side busy |
| NO CARRIER | No network |
called_address
String. IP V4 address in the form w.x.y.z, which identifies the called party; if it is provided, the MT will automatically set up a virtual call to the spec-ified address after the context has been activated. This parameter is currently not used and needs not to be specified.
L2P
String. Layer 2 protocol to be used between the TE and MT.
This discussion is about whether modem communication can be made quicker which might be of interest for us.
From the Pycom user forum again:
People asking themselves whether such a scenario would work on the Pycom devices:
Connect a device on the FiPy WiFi AP that routes the data to an IoT server using the Sequans IoT modem.
They received an answer from Pycom support which is stating it might not be possible at all: